A couple people mentioned Short Auth Strings (SAS) in the fingerprint thread, e.g.
Alice -> Bob : H(g^a) Alice <- Bob : g^b Alice -> Bob : g^a K = H(g^ab) SAS = H(K) truncated to a few bytes An attacker executing the protocol with Alice or Bob won't be able to control the SAS value. So to perform a MITM the attacker would have to create sessions with both Alice and Bob until getting matching SAS (assume Alice and Bob compare the SAS somehow). Thus SAS can be shorter than fingerprints (2 or 4 bytes in ZRTP, 8 for OTR's Session ID). But there's downsides: (1) Unlike a fingerprint which can be checked against a business card, website, or mutual friend, SAS need to be checked against a fresh value from the other party. In practice, SAS are mostly used by phone protocols, since users can speak the SAS to each other (assuming voice impersonation is hard). (2) SAS add extra communication for the hash commitment. That's challenging for an "async" protocol like TextSecure or Pond. For example: With fingerprints instead of SAS, Alice could post her g^a values and long-term public key to a server. When Bob wants to send Alice a first message, he could download g^a and the long-term key, check the fingerprint, compute a shared secret involving all keys, and encrypt and send the message without delay. With SAS, Bob could download a hash commitment from the server, but would still have to complete a round-trip with Alice and check the SAS with her before sending the first data message. In sum: - SAS seem well suited to voice apps. - SAS are maybe useful for text chat, though I'm not sure how much they're used in OTR compared to fingerprints or PAKE (OTR is unusual in having all three options. Is there any data on which users prefer?) - SAS don't seem suited to async protocols. Anyone see things differently? Trevor _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
