> (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
This is your problem ^^^^^. DH key exchange doesn't exchange known values, it creates a new value randomly each time. You can't use it as a form of secure transfer. It would be possible with other key exchange systems, but I can't really say I like it because A) It makes traffic analysis *really* easy, since all you have to do is watch the same data flowing through all the hops. B) It allows coordinated weakening attacks. Imagine one bad node is able to switch the encryption to a very weak variant (say a weak key or something). He doesn't know where the data ends up, but if he can find it he can decrypt it at another MITM point. With point-by-point encryption his attack only lasts one hop before its thwarted. > 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. Thats true now. > (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. Latency remains the same. The initial connection time is reduced, but the overall system runs at the same speed unless one node is so so slow that it can't handle the crypto. Yes, it does decrease CPU usage. > These seem to me to be strong incentives without any drawbacks. Security drawbacks, and protocol complications. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20000817/b96a5db4/attachment.pgp>
