> Date: Fri, 18 Aug 2000 10:51:10 +0700 > From: Oskar Sandberg <md98-osa at nada.kth.se> > > On Thu, Aug 17, 2000 at 02:24:47PM -0400, Michael Wiktowy wrote: > <> > > Why do this? > > The passing of the data only has to wait for one DH key exchange per node > > per stream > > where the DSK is exchanged. > > (as opposed to a symmetric key generation per node per stream / DH key > > exchange per > > node per stream / decryption per packet per stream / encryption per packet > > per stream) > > This decreases latency, decreases CPU usage and increases transfer speed > > while > > keeping the full robustness of the data stream encryption and not > > sacrificing traffic > > analysis > > obscurity much more than it already is. > > > > These seem to me to be strong incentives without any drawbacks. > > > > Can you see any badness here that I've missed? > > There is a huge drawback, and that is that for anybody who has access to > one of the nodes in the chains, all the other connections are > exposed. This means that exposing somebody only requires being one of > maybe 20 nodes that actually get the request, and being able to do very > basic wiretapping on the network. > > Not good enough. > > Besides, as has been said a number of times, the overhead of > decrypting and the reencrypting is actually pretty small, with a good > implementation filling a 10 meg pipe will still only eat a fraction of a > recent processor. The DH exchange is what really slows it down, and you > still have that.
OK, OK ... You and Scott have convinced me that this is a bad idea from a traffic analysis stand point. I would just like to deliver the final lethal blow to this idea that everyone (including me in generating the idea) overlooked. In order to find out where to forward the insert/request/whatever, the node needs to decrypt the stream in order to determine the key value to do it's comparison with the references in the stores. This dictates that the encrypted stream must be decoded at each node to implement any self-sorting in freenet. The only way around this would be to send the key in the clear, which kind of defeats the whole purpose of the internode encryption. One thing I don't follow though is Scott's insistance that you cannot securely swap any symmetric key that you want with DH key exchange. Everything that I have read (which admittedly is not copious quantities) indicates that you get to choose your symmetric key depending on what kind of encryption method you select to use on the stream. Can't the shared secret that is derived from the public and private keys on both nodes be used to encrypt and exchange any value for the symmetric key that you want? I understand that it would be a good idea to use a random key to foil traffic analysis, is that all that is being said? Or is it the fact that the DH key swapping is not secure when you have low entropy keys (i.e. knowing something about the key makes it *way* easier to find out the full key)? I am just curious. Thanks for your feedback. Mike PS: I'm going to transfer this thread over to freenet-tech (where *a lot* of these discussions would be if they were not largely ignored over there - Is freenet-dev the Developer's mailing list or the Development mailing list?) PPS: I'm going to order myself a copy of "Applied Cryptography" and then we will see if the "Ian's missing chapter/NSA exported book sabotage" conspiracy has any basis :] _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
