Current status: in TLS working group telling people about how amazing Short Authentication Strings are.

Want to do hybrid SAS with PQC and classical? It's basically the exact same protocol, no additional messages.

Worried that you have to exchange a password, so you might as well exchange a key? SAS basically forces you to the main use case of pairing to local devices.

Worried about people choosing bad passwords? SAS is chosen for you.

But are SAS memorable? Just map them to Unicode emojis. One to two will suffice.

@sophieschmieg This sounds like trouble - SAS sounds like it significantly reduces how much entropy fits. Also I fear having to tell 🙁 from â˜šī¸ in a 3 guesses or you're locked out scenario.

@Epic_Null the way to solve that is doing a "show three options and pick" protocol. And selecting only a subset of emojis to be valid.

The neat thing about SAS is that it doesn't need all that much entropy to work, a four digit PIN is usually seen as sufficient, as it makes the attack unpalatable.

@sophieschmieg I am going to need a LOT more technical justification as to why a four digit pin is okay for anything online that is not a second factor for a much larger secret.

@Epic_Null the trick to SAS is similar to PAKEs: the thing on the wire is high in entropy, and never the same for multiple tries. So trying to brute force the authentication string simply doesn't work, as it is not predictable and random.

The way this technically works (for the ECDH SAS) is that Alice computes an ephemeral key pair, but instead of sharing the public key only shares a hash of the public key. Bob then also creates a key pair, and shares the public key. Once Alice has received Bob's public key, she reveals her public key in the third message, and the SAS can be derived from the shared secret.

The security property comes from the fact that we can divide this exchange into two phases for each party, a commitment phase and a derivation phase. All random decisions happen in the commitment phase: Alice and Bob chose their key pair, but neither of them knows what the other party will/has chosen at that point. They then commit to their choice, via hash in Alice's case and via revealing their public key in Bob's case. Only after having committed do they learn about the choice the other party made, but now there is no going back: all the following steps are purely deterministic. That means the resulting SAS is determined by entropy from both sides and cannot be predicted by either side. So a MitM attacker will inevitably produce a different SAS with one party than with the other, and is easily detected.

[TLS] Device Pairing - PAKEs v SAS

Search IETF mail list archives