> 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. 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. > socket layer data handling versus the higher layer. SSL for example > handles this by specifying a different port number for the "secure" > versions of the protocols. This makes sure there is no conflict where This is a really great solution. Too bad it won't work for us. We could have even port number secure and odd port numbers insecure. Just kidding. That's silly. :-) _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
