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 _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
