Matthew Toseland wrote:
> I didn't take them out of the signatures, only out of the wire protocol. This 
> is AFAICS harmless.

Cool, you're probably right.

> 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.

How so? Isn't the information in an SSK encrypted? If ARKs are secure at
the moment, why would this make them insecure?

> 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.

> 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.

> 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.

> 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.

Cheers,
Michael

Reply via email to