-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 About the SAS: ZRTP uses a so called Hash Commitment with traditional Hashes before generating SAS values for voice comparison.
See http://zfone.com/docs/ietf/rfc6189bis.html#HashCommit "The use of hash commitment in the DH exchange constrains the attacker to only one guess to generate the correct Short Authentication String (SAS) in his attack, which means the SAS can be quite short. A 16-bit SAS, for example, provides the attacker only one chance out of 65536 of not being detected. Without this hash commitment feature, a MiTM attacker would acquire both the pvi and pvr public values from the two parties before having to choose his own two DH public values for his MiTM attack. He could then use that information to quickly perform a bunch of trial DH calculations for both sides until he finds two with a matching SAS. To raise the cost of this birthday attack, the SAS would have to be much longer. The Short Authentication String would have to become a Long Authentication String, which would be unacceptable to the user. A hash commitment precludes this attack by forcing the MiTM to choose his own two DH public values before learning the public values of either of the two parties. " Regards Dominik On 23.05.2013 20:59, Wasabee wrote: > can someone give a few lines of explanation on how the Retained > shared Secret (RS) is used in ZRTP? second, is it possible for an > attacker to force an RS validation error (e.g. simulating network > connection error by having a router drop packets) and then MiTM the > DH handshake? the SAS is only 4 characters. presumably this is > ascii so 2^27 = 531441 possibilities. On average the active MiTM > attacker would need to try only half of them (real time) to find a > collision. Do parties first commit (e.g. send H(N,g^x)) prior to > sending their g^x to avoid the latter problem? If so, then what's > the use of the SAS? > > Sorry if all those questions are trivial... > > Wasa > > On 23/05/2013 19:05, Dominik Schürmann wrote: >> They have implemented ZRTP for end to end security. It works with >> a diffie hellman key exchange, while protecting against >> man-in-the-middle attackers by comparing Short Authentication >> Strings (SAS). When you know the voice of the other person you >> can exclude Eve. >> >> see https://jitsi.org/Documentation/ZrtpFAQ >> >> Regards Dominik >> >> On 23.05.2013 20:01, Jonas Wielicki wrote: >>> Jitsi is XMPP or SIP. For the text-part, they have built-in >>> support for OTR. Otherwise, there is no end-to-end secrecy as >>> far as I know. >>> >>> For voicecalls, they have something similar, with some >>> shared-secret verification which is validated using the >>> text-channel, which is best secured with OTR I guess. >>> >>> I know of no throughout reviews of their model though. >>> >>> regards, Jonas >>> >>> _______________________________________________ cryptography >>> mailing list [email protected] >>> http://lists.randombit.net/mailman/listinfo/cryptography >> >> >> _______________________________________________ cryptography >> mailing list [email protected] >> http://lists.randombit.net/mailman/listinfo/cryptography > > > > > _______________________________________________ cryptography > mailing list [email protected] > http://lists.randombit.net/mailman/listinfo/cryptography -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJRnmn+AAoJEHGMBwEAASKCDP8H/id2iQhe53uzeZH20K89mcKd 44WWMUkyo9MROK5nH2/7B+KhrWQVLTqeToE3SqfwSBnQiBde+CY2lPnDgvN+M1ax 8p6ES2umbgHXM9Cg9qzW+AKEW7QmoyeaVu4f6g9zsrJDOMzx9XjWLoKQjKgjNL89 Bw1rVbFKoZEmT/XzEBrzm8UyxyYClXQvOe5XQ8o5ICeMKvCwFCCmKDMFjMyDsInf 2x+mxJqoImntWKQp9SigdLIxQ0upt3zK0XsvSKbSB6eupLgv6SpgiUsP1MWFk9ML q0dzom+A5BS8E8UD5GOXUunOCAGZNhoLAGPgEZkgeyl6pEmV/bQW35VeGHDqge0= =uVm2 -----END PGP SIGNATURE----- _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
