> Date: Thu, 17 Aug 2000 00:28:39 -0500 > From: "Scott G. Miller" <scgmille at indiana.edu> > > > What I am saying is that in the initial DH key exchange, the random sessi= > on key > > that gets established can be the random Message ID that is generated by t= > he client. > > The whole node chain would then share the same session encryption key and > > therefore, would just forward the encrypted stream along and decode it fo= > r its > > stores if it has the room for it. The only problem I see with this is tha= > t traffic > > snoopers will see the same stream going into a node as coming out. Since = > they > > shouldn't know the contents of that stream in the first place, I don't kn= > ow of the > > implications of this on the security of the whole system. They could prob= > ably > > already take a 99% accurate guess that two streams (incoming and outgoing) > > are equivalent via connection timing. > No no no. That doesnt work. Remember that you have to *get that key to > the others in the chain securely*. To do that you have to do a key > exchange. Its a catch-22.
I think you are misunderstanding what I am saying here perhaps because I am missing something fundamental and what I am saying might be absolutely insane due to my misunderstanding of encryption systems :]. I will try to use more correct termonology to explain myself clearly. I have read the "DH key exchange for dummies" (ref: http://securityportal.com/topnews/dhkeyexchange20000706.html ) and am not proposing getting rid of that section of the process at all. We would still use DH key exchange (or a PKI in the future). What I am wondering is this: Can the symmetric key that gets passed via the DH exchange be derived from the Message ID generated by the client and be shared securely (via subsequent DH exchanges) along the entire node chain? So that: step 1: client generates Message ID step 2: client derives a symmetric key (DSK_1) from Message ID step 3: client does DH key exchange to Node 1 and passes DSK_1 to Node 1 securely using shared secret provided by DH mechanism step 4: client starts transfer of data to Node 1 encrypting with DSK_1 step 5: Node 1 does DH key exchange with Node 2 and passes DSK_1 (as provided by the client) to Node 2 securely using shared secret provided by DH mechanism step 6: Node 1 simply forwards the encrypted stream directly to Node 2 since Node 2 can decrypt it with DSK_1 step 7: Node 1 decrypts data stream using derived symmetric key step 8: Node 2 repeats step 5 to step 7 with Node 3 etc. 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? Mike _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
