[messaging] DH vs PAKE vs SAS

[Brian Warner]

Just musing on the basic "stage directions" of the different
pairing/introduction protocols we've been talking about. In each one,
who does what first?:

* PAKE: Humans agree on a secret. Later, they tell their computers about
  it, and point them roughly at each other. Computers exchange packets
  (PAKE). Pairing complete.

* DH+SAS: Humans point computers roughly at each other. Computers
  exchange packets (DH, then SAS on the session key). Computers show SAS
  validators to humans, humans compare validators, click "yes". Pairing
  complete.

* Static pubkey hashes on business cards: Humans prepare cards. Humans
  exchange cards. Later, humans transcribe/scan fingerprints into
  computer. Computers exchange packets (authenticated DH). Pairing
  complete.

I like the simpler math of SAS, and how it doesn't ask the user to
handle secrets, but unfortunately it requires that the humans interact
both before and after the online phase. It works fine if we're in the
"both people brought their computers" case, but the one-computer or
zero-computers cases mean you need *two* face-to-face meetings. Ick.

(SAS only validates one direction, so you need to compare twice as many
bits, but you can compare both SAS strings at the same time)

Static-pubkeys-on-cards matches normal non-cryptographic human
protocols, so it's easy to understand, and only takes one meeting. But
you must plan ahead, and then later you have to transcribe the whole key
(to prevent offline attacks), which is a drag unless we're allowed to
rely on QR scanning or something.

Also, I just remembered that keys-on-cards allows the usual unknown-key
misbinding attack: I print a card with my name on the front, but the QR
code on the back is for somebody else's pubkey. If I time things right,
I might convince you that I authored a message written by somebody else.
Or more likely, you scan my card without looking carefully at the name
on the front, and the pubkey you get from my QR code has somebody else's
name on it, enabling the reverse attack (you think you're talking to
them, but really I can read the message).

So I kind of want something has the keys-on-cards flow, but doesn't
require people to type in the whole key. Maybe some sort of hybrid
scheme would enable that and also block the unknown-key attack. And we
should probably put the QR pubkey on the same side of the card as the
human-readable name, and record the whole image for later use in the
addressbook.

cheers,
 -Brian