On Friday 16 November 2007 22:33, Michael Rogers wrote: > Matthew Toseland wrote: > > 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. > > They don't need to be real-time, just on the order of the lifetime of an > IP address (24 hours). They do need to be bidirectional, for reasons > discussed in my other email.
For the exchange to be secure, both sides must be un-tamperable, or one side must be un-observable. Both sides un-tamperable: classic noderef exchange. If either side is tampered with, Mallory can get connected to one side but not the other. If both sides are tampered with, Mallory can get connected to both sides and MITM. An out of band verification is necessary to make this safe. One side un-observable: Alice unobservably gives Bob a one-time invite (hash of a temporary pubkey plus address), Bob responds with his noderef, encrypted using her one-time invite. An out of band initial exchange is necessary to make this safe. We're assuming different attack models here. Both are valid for certain assumptions. > > > 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. > > Like I said, I think this is a great idea. But we should also have some > form of short, cut-and-pastable invitation for situations where file > transfer isn't possible. I didn't say it had to be long. > > > 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. > > I haven't heard any suggestions that would achieve this. The closest I > can think of would be exchanging email addresses and GPG key > fingerprints, and emailing each other when you're ready to exchange > invitations. The need for mutual authentication means there's no one-way > solution. Not valid: If we can exchange a one-time invite unobservably, we can connect securely. OTOH if both sides are observable and potentially tamperable, we need an out of band verification (i.e. an untamperable verification). > > > Instant gratification is vital. Minimizing the work for the > > user is vital. Effective security is easy security: > > The easiest security of all is no security. There are tradeoffs. :-) > > > Although they will be easy to spot on IM and email even if they are raw > > base64 strings, won't they? > > I reckon it would be tough to write a filter that matched random > 50-plus-character base64 strings without getting a lot of false > positives... but I haven't tried. The point is, they'd be harder to spot > than freenet:// URLs or whatever. > > > Even email qualifies as > > difficult to surveil if you process the invites reasonably quickly. > > You want to race your own ISP to see who can read your email first? ;-) :| > > > 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. > > I accept that usability is very important, but there comes a point where > you're just offering people a false sense of security. If the whole > system hangs on a password sent in an unencrypted email then people > might as well stick to Gnutella. At least Gnutella has TLS, which > requires an active MITM attack... > > > 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. > > Sounds interesting, but can you give details? I can't see how any system > without a two-way prior exchange of identities can provide two-way > authentication. Needs to be reexamined in the light of the above. > > Cheers, > Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20071117/80c2a763/attachment.pgp>
