Ring needs a SAS(Short-Authentication-String)
Issue generated from Tuleap's migration script. Originally submitted by: Antonio Banderas (ridiculousmouse)
In order for ring to completely secure itself against a MiTM attack it needs an SAS for users to verify via the audio channel. The current method for preventing an attack is not sufficient enough to protect against an attacker with the sufficient resources and knowledge. An SAS would be meaningful as long as the string is never transmitted and only kept locally, users must say the string out loud at the beginning of the call over the encrypted audio channel to verify the DH key agreement hasn't been tampered with.
"The Diffie–Hellman key exchange by itself does not provide protection against a man-in-the-middle attack. To ensure that the attacker is indeed not present in the first session (when no shared secrets exist), the Short Authentication String (SAS) method is used: the communicating parties verbally cross-check a shared value displayed at both endpoints. If the values do not match, a man-in-the-middle attack is indicated. (In late 2006 the US NSA developed an experimental voice analysis and synthesis system to defeat this protection, but this class of attack is not believed to be a serious risk to the protocol's security.) The SAS is used to authenticate the key exchange, which is essentially a cryptographic hash of the two Diffie–Hellman values. The SAS value is rendered to both ZRTP endpoints. To carry out authentication, this SAS value is read aloud to the communication partner over the voice connection. If the values on both ends do not match, a man-in-middle attack is indicated; if they do match, a man-in-the-middle attack is highly unlikely. The use of hash commitment in the DH exchange constrains the attacker to only one guess to generate the correct SAS in the attack, which means the SAS may be quite short. A 16-bit SAS, for example, provides the attacker only one chance out of 65536 of not being detected."
" If you have a man-in-the-middle attack happening with legitimate certificates being used you can be sure that your "secure" connection is really not so secure. Any and all of your data that's being encrypted over a TLS connection that is being attacked in this way is completely decryptable by the party performing the attack. This is because the key that is being used in the encryption/decryption process is theirs! Of course they'll be able to decrypt it. "
As history has shown us, even if every method of key agreement is used there is no way to guarantee that the key agreement was negociated with the proper party. Even if OpenDHT has seemingly guaranteed the communication is to the proper party we do not know if OpenDHT has vulnerabilities or methods of attack against it. There is no way to know if a vulnerability exists in any of the cryptographic libraries ring uses.
Adding a SAS is not necessarily difficult and adds an extra layer of security. It also allows the users to be assured the communication is legitimate and configured properly.
For further clarification I am not saying Ring should use ZRTP(which SAS originates from), in fact I feel the current method for key-agreement is good but an SAS will not be hard to add and adds an extra layer of security.