Matthew Toseland wrote: > So when the pubkey is exchanged, we also send the nonce? What is the point?
The nonce functions as an IV for the obfuscation - but if the pubkeys are single-use then maybe an IV isn't necessary? > I don't see what the problem is with one-time invites. Obviously if we have > an > MITM during out-of-band exchange of invites, we're screwed, but that's the > case with anything we set up. It's not about MITM, it's about an attacker seeing (but not modifying) the invite, and connecting to the responder. Without a two-way exchange of invites, the responder can't distinguish the attacker from the genuine initiator. (MITM is different because both the responder and initiator are deceived.) > How would two-way invites work and why do we need them? They'd work like short refs, but you'd only be able to use them once: A generates a single-use pubkey and gives the hash to B. B generates a single-use pubkey and gives the hash to A. When A connects to B or vice versa, each can authenticate the other using the pubkey hash from the invite. After authenticating each other, the long-term keys and other details are exchanged. An attacker who sees (but can't modify) either or both of the invites can't impersonate either or both of the peers. Contrast this to one-way pubkey invites, where the attacker can impersonate the initiator, or passwords, where the attacker can impersonate both peers. In my opinion it's quite likely that an attacker will be able to see but not modify some people's invites, so the protocol should be secure in that situation. > If they see the password, yes. However the advantage is that the password can > be easily and safely exchanged out of band i.e. on a piece of paper, over the > phone etc. In theory passwords can be exchanged securely. In practice I don't think most people will bother - they'll send it by email, IM, text message, write it on a post-it note and stick it to the monitor, etc. If we use two-way pubkey invites, it's OK for them to do that. If we use a one-way pubkey invite or a password, it's not OK. Instead of fighting human nature we should design protocols that are secure in the face of human nature. > We need to design it so that the Correct Behaviour is easy. Yes! That's exactly why passwords are a problem. If there's an option to use passwords, nobody will use pubkey hashes, even over an insecure channel. If there's no option to use passwords, people will tolerate the minor inconvenience of using pubkey hashes. > Lots and lots of geeks exchange GPG signatures at conferences. Lots and lots > of geeks know other geeks at work, at university, at LUGs/2600's/whatever. ...and lots and lots of those geeks don't bother GPG-signing their email, let alone encrypting it, because there's an easier but less secure option. Myself included. > If it's going to be emailed, they may as well just email a full noderef. It > will be unpacked at the other end and it should be a few clicks to add the > ref. We're not talking about email here. Maybe instant messaging, but again, > a file is easy to send with most IM clients. If file transfer was so easy we wouldn't have resorted to pastebins in the first place. What about IRC, phones, text messages? > And above all it depends on just how hostile the environment is. Right now > it's not very hostile most places; we need to build a true darknet so that > the network will work when it becomes more hostile. That depends on making it > easy. We should make it as easy as possible, but no easier. ;-) I don't think the security/usability tradeoff for passwords is acceptable when pubkey hashes are only slightly less convenient and much more secure. We should not hang the security of the entire system on an easily-sniffed password. Cheers, Michael _______________________________________________ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
