[messaging] Short Auth Strings

Trevor Perrin trevp at trevp.net
Fri Jan 31 09:24:50 PST 2014


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


More information about the Messaging mailing list