> Date: Wed, 16 Aug 2000 20:21:32 -0500 > Subject: Re: [Freenet-dev] RE: Freenet behind NAT > From: "Scott G. Miller" <scgmille at indiana.edu> > > > How big a deal will it be? I realize that most of the crypto key generati= > on for > > inserted data will be handled by the client. There is all the DH exchange > > overhead (not much CPU involved there).=20 > Actually, the DH exchange is likely to be the worst blow. It takes about > 300ms on my p2-300. So expect a 1-2 second pause there.
That is a one time per request/insert latency issue though. It doesn't even have to multiply by the number of nodes in the chain since the insert can start before the whole chain gets established (the insert can be aborted if a collision is found). > > > There is the constant encryption on > > the sender node side and decryption on the receiver node side with a subs= > equent > > reencryption that I think would be more CPU intensive. > > I don't really have a good feel for this though. All I can go on is my us= > age of ssh. > > The initial connection is fairly slow to my 486, but after that the rest = > of the > > session > > is only slightly slower than telnet. I suppose most of the effect on the = > freenet of > > running 0.3 on a slow CPU box would be vastly increased initial connectio= > n latency. > Yeah. > > > One thing that might help the encryption/decryption/encryption speed woul= > d be to use > > a shared session key for the whole insert node chain (it could even be th= > e Unique > > Message ID already present in the system). That way the first node encryp= > ts the > > message > > and all subsequent nodes just decrypt and forward and the last node just = > decrypts. > > It cuts out a reencryption for every hop but I don't know how it affects = > traffic > > analysis. > No, because you still have to securely trade that key with your neighbors, > and that would take just as long as generating a separate key. What I am saying is that in the initial DH key exchange, the random session key that gets established can be the random Message ID that is generated by the 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 for its stores if it has the room for it. The only problem I see with this is that 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 know of the implications of this on the security of the whole system. They could probably already take a 99% accurate guess that two streams (incoming and outgoing) are equivalent via connection timing. My understanding is that the same data encrypted by two keys is more vulnerable to decryption than multiple copies of the same encrypted data. Is this correct? If so, it might be worth sacrificing that 1% traffic analysis obscurity for robustness of encryption, decreasing CPU load and increasing speed of transfer. > On the > encryption/decryption side your right, but its really not that big of a > deal. Once the streaming begins you're talking maybe an initial 200-300ms > delay. After that its likely to be just as fast. I don't see how decrypting/storing/encrypting/sending would be as efficient as forwarding/decrypting/storing latency-wise or CPU load-wise. This is also a continuous CPU load (as opposed to the one time DH exchange load) as each packet in the stream is encrypted with the session key. So the effect is multiplied by the number of streams that the node is handling at any one time. If it represents an untolerable security issue then I understand completely. But if this option open so that shitty boxes can handle more simultaneous connections (with the possibility of faster boxes making the decryption/encryption key swap), this seems like a avenue to examine closely since the transfer rate will be representative of the slowest link in the chain. > > > All the key verification that I guess is planned for 0.4 (or is all that = > included in > > 0.3) > > would be another load on top of that though. > Actually, there's a decent chance that the authentication won't affect > performance at all, or may even vastly improve it. I'm not sure that I buy that statement. The only way it would help performance would be to cull down the bogus transfers initiated by cancer nodes. Under normal operation, the nodes, in order to validate the data, will be going through the same CPU intensive steps as the client did to generate keys in the first place. I think I have beat this point to death ... I just want to get some continued use out of my old hardware without hurting the freeenet; the speed or the security. Mike _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
