Brandon <blanu at uts.cc.utexas.edu> wrote: > > I assume that either the server or the client would have to send some kind > > of message to initiate the key exchange negotiation? So there would be > > a backwards compatibility issue here, in the event that the other side > > does not understand the key exchange request message. In that case it > > would be good if the node could fall back on an unencrypted connection. > > I would assume that encrypted connections would be specified using a > different address in something like the new multilayered addressing scheme > I brought up. So we would have dh:tcp/localhost:19114 for encrypted > connections using DH Nothing before tcp means use the default, which > would be unencrypted. I'm not at all sure if this is the best way to do > things, but it seems okay. Another way would be to have a handshake > exchange in which the node could say what encryption methods it > understood.
It seems to me to be quite undesirable and inflexible to make the encryption method part of the address. For example, what if you have a reference in your datastore from last year which points to: twof:tcp/piclab.com:19114, but since then twofish has been broken and everyone is using threefish now? Or if you have a node which supports multiple encryption types you will have a messy proliferation of different addresses for the same node, and you might end up using a weaker algorithm than you have to. (e.g., Alice supports both DES and rot13, Bob only supports rot13, so Bob's reference to Alice's node is rot13:tcp/alice:19114; Chandler gets this reference from Bob, but even though Chandler speaks DES he ends up speaking rot13 to Alice.) Cipher negotiation is a good thing. > This is undesirable in situations when you don't want people > to know that you're running a Freenet node, so you eschew contact with > other Freenet nodes. You want to 1) make connections in straight encrypted > mode and 2) have any nodes that find out about you from DataSource make > connections to you in straight encrypted mode. But you can't just start speaking encrypted gibberish right away. There has to at least be a key exchange first. =) Why not just make the negotiation look like something commonplace like SSH2? (Or even just -use- SSH2? I'm not too familiar with the issues involved, but my impression is that the transport part is a generic way to negotiate and secure any transport-level connection?) theo _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
