-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/06/12 07:59, Brian Warner wrote: > Assuming that Alice and Bob have some way to transfer 16 bytes > securely is part practicality and part pragmatism. The practical > part is that a targeted attacker (one who knows Alice and Bob and > specifically wants to intercept their invitation exchange) has to > watch them constantly, via all conceivable transmission channels, > waiting for that one moment to strike.
I wouldn't agree that the attacker has to watch all the communication channels all of the time - she can watch some of the communication channels some of the time and only attack if she sees an invitation code. Unreliable or opportunistic attacks are still attacks. > A non-targetted attacker (who's so lonely that they'd be happy to > MitM *anybody*'s connection, even complete strangers) could, say, > grep the IRC server feed for things that looked like invitation > codes and claim them before their intended recipient could. But if > they don't know much about the recipient, they probably aren't in a > good position to MitM their traffic, so the most likely attack they > could mount would be invitation-stealing, rather than MitM (Alice > invited Bob but gets a stranger instead who doesn't even know she's > supposed to pretend to be Bob, Bob gets an error and complains to > Alice through their outbound channel, Alice deletes the entry and > tries again). Why does Bob get an error? I'm imagining something like this: * Alice emails the invitation code to Bob * Mallory reads the email and joins the channel * Alice and Mallory do the invitation dance * Alice leaves the channel * Bob checks his email and joins the channel * Mallory and Bob do the invitation dance * Bob leaves the channel * Mallory has established keys with Alice and Bob, who think they've established keys with each other What am I missing? > The pragmatic part is that, if Alice and Bob can't even manage to > transfer 16 lousy bytes without getting MitM'd, they're screwed > anyways, and no sensible amount of protocol cleverness can help > them :-). We should distinguish between an attacker who can read the invitation code and an attacker who can replace it with another code. An attacker who can read the invitation code doesn't seem far-fetched to me - she could be sitting on Alice's LAN, for example. The current invitation protocol seems to be vulnerable to such an attacker because it sends a secret value in plaintext. On the other hand, an attacker who can replace the invitation code with another code seems more far-fetched to me. So I think it's worth defending against the read-only attacker even if you don't defend against the read-write attacker. For example, could Alice and Bob exchange invitation codes derived from their public keys, instead of using a secret value? Cheers, Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJP2lNAAAoJEBEET9GfxSfM/88IAIhl7OJ+Dy8lmfCkCyAXqoPV 28A1yUjmJA0L92a2LSihrLM+jk7X5I4HLOC+DfhqY5aW+Y6PoUav3P/JLHyf3Wal uiVxL/oUHEq+r2ASu6DcWy2/9DtFHSnLI/vqCMMkm3HbSJFPyLDAzEd+R1MT08m+ Xu8gNpC4SiL7sAgstJTimcTcGctYHHvpqfEVX7Pl6CvIqGjb8XSEt5idkp6qvzno IjDZOdmz4m5KVDO+QXatAa7Re8n+1r3S/DsO2qAUl2Uds7entW+kMd6D847IZAUH ysGMorK1JabAhRwEVMKxr3DPtPXNho0LV1lOkVOJFfYD4ueQQFCtCOv3PJUuO2k= =sDTf -----END PGP SIGNATURE----- _______________________________________________ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
