On Friday 16 November 2007 18:54, Michael Rogers wrote: > Matthew Toseland wrote: > >> JFK doesn't exactly strike me as a bloated protocol. In fact it was > >> designed to be the simplest possible protocol that would get the job > >> done securely. What did you leave out? > > > > Only the constants that can be happily implied: the bits we don't need in > > regular Freenet connections i.e. the pubkeys. > > You took out the pubkeys? But without both ends signing their own and > the other's pubkeys, how do you prevent MITM?
I didn't take them out of the signatures, only out of the wire protocol. This is AFAICS harmless. > > > The ARK could be inserted using the node crypto key yes, but I'd really prefer > > it wasn't, because the pubkey can be read by any node which has the ARK: > > That's not quite what I'm suggesting; more like the reverse. The node's > pubkey and all the other information from the current ref are inserted > under the ARK key, and the short ref contains the ARK key. You can > either use it to retrieve the rest of the information from Freenet, or > to verify the information exchanged during JFK. In other words, you can connect to a node having only its ARK? Hmmm.. this still gives away a lot of information about nodes (including darknet nodes) to any node listening to SSKs. > > > Okay, so how do we do this? We need to authenticate in both directions: the > > client needs to prove it has the invite, and the server needs to prove it is > > the server. > > I think we need to go further than that. Some users will exchange > invites over eavesdroppable channels, so we need mutual authentication: > the client must prove it's the client, not an attacker that's seen the > invite. A two-way exchange of pubkey-based invites is the only way to do > that. This will cost us a lot of users IMHO. We cannot assume that all invites will be real-time and bidirectional. It needs to be easy to get onto the network. We need to be able to send a friend an invite and when they get around to it they can double click the jar (with the invite built in) and install Freenet and connect to their friend, possibly with a password being exchanged at the last minute. We need to be able to give somebody a business card at a conference/uni/work and when they find it a week later it still work, and work instantly. Instant gratification is vital. Minimizing the work for the user is vital. Effective security is easy security: perfect theoretical security will be worked around (in this case by not using freenet at all), if it's not easy. > > There are lots of channels (phone, IM, email) where an attacker can > easily eavesdrop but can't easily perform real-time MITM, especially if > the invites are hard to spot (ie raw base32 or base64 strings rather > than freenet URLs). Right. Although they will be easy to spot on IM and email even if they are raw base64 strings, won't they? > > > If we use JFK with I's real pubkey and R's temporary pubkey: > > - If Eve sees the invite, she can decrypt the exchange, and see the pubkeys, > > but she can't get connected. > > She can connect to R by posing as I, because R doesn't know I's > identity. If there's any chance of the invite being seen, we need > two-way invites. Doh. This is true. This is inherent in invites. Invites should only be used over channels which are difficult to surveil. Even email qualifies as difficult to surveil if you process the invites reasonably quickly. > > We could offer a choice of one-way or two-way invites, but since users > don't generally know whether they're under surveillance, I don't think > we should leave the choice up to them: we should only offer two-way invites. For every extra mouseclick you reduce your audience by a factor of two.We *REALLY* need darknet, far more than we do perfect security in invites. We need to provide the tools for people to do the right thing if they can be bothered, and to get connected in some way if they can't. The only realistic compromize I can think of would be to have a one-way invite combined with offline verification: You feed the invite to your node, then it generates a password which you have to send back to the inviter. > > > Agreed, with one minor change: JFK uses temporary keys on both sides and > > exchanges the real ones encrypted once Ke is known. Benefit is that Eve > > cannot see the pubkeys even if she saw the invite. > > Then subsequent handshakes use the long-term keys? Sounds good. Of course, subsequent handshakes will use the normal link crypto setup i.e. JFK without pubkey exchange. > > Cheers, > Michael
pgpiFYmUhUzrj.pgp
Description: PGP signature
_______________________________________________ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
