> Hmmm, yes, I see your point.  I guess we should not go with the
> public-key in address idea - but I still fail to see why people are
> saying inter-node encryption is so difficult to achieve.

However, we need to have an initially encrypted connection. Under that we
can negotiate and switch crypto methods. But the initial negotiation needs
to be encrypt too. It helps against man in the middle attacks because they
can't intercept or spoof the key exchange if it's encrypted unless they
first break the initial layer of encryption. Also, it will make detecting
nodes more difficult because not only will you have to actually run a
Freenet node (insteading of using a prefab port scanning tool), but if the
node only accepts encrypted connections (optionally, configurably, of
course) then you'll have to find the key to use to talk to that node. But
if you find the node's key then you already know it's a node. So,
basically, port scanning is useless.

I don't see any way to make the very first initial connection to the node
encrypted unless a PK is distributed along with the address. It's okay if
the node changes encryption methods or keys because 1) you are just using
it to exchange keys for the cipher of your choice anyway, and 2) you need
a way to inform nodes of your changing IP/DNS address anyway. Nodes will
probably move around every now and then, probably more often than they
switch keys or ciphers, especially if the initial cipher is a standard
among most nodes, which it probably should be.

But then this is all for later anyway because it relies on the key/cipher
negotiation and stream encryption to happen under it. So we (or Scott,
rather) should go ahead and implement that first, and then we can add this
layer.



_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev

Reply via email to