> Date: Wed, 16 Aug 2000 14:08:50 -0500 (CDT) > From: Brandon <blanu at uts.cc.utexas.edu> > > > I think that was what Oskar was saying. Hopefully this will be implemented > > in 0.3 since I am uncertain whether my 486 firewall can handle the higher > > CPU load of the new crypto code but I know that my internal Athlon will > > happily crunch on it. I suspect that I will not be alone in not being able > > to run > > The crypto shouldn't really be that big a deal. >
How big a deal will it be? I realize that most of the crypto key generation for inserted data will be handled by the client. There is all the DH exchange overhead (not much CPU involved there). There is the constant encryption on the sender node side and decryption on the receiver node side with a subsequent 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 usage 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 connection latency. One thing that might help the encryption/decryption/encryption speed would be to use a shared session key for the whole insert node chain (it could even be the Unique Message ID already present in the system). That way the first node encrypts 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. 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. Any thoughts? Mike _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
