Ian Clarke wrote: > One thing I am personally a-little unclear on is what encryption > negociation mechanisms people hope to use (ie. a:"I talk blowfish and > twofish" b:"I talk XOR and twofish" a:"lets talk twofish" b:"ok"), and > how these will integrate into handshaking, and also how these will > integrate into the current mechanism (ie. maintain backward > compatability - which I think we should do if possible).
Again, allow me to point to the experiences of numerous other efforts that were faced with the same problem. Be it SSH, TLS, or an abomination such as IKE, the inevitable consequence of providing a choice of cryptographic algorithms is that the weakest algorithm will stay around forever. In addition, implementing the algorithm negotiation tends to be the *vast* majority of the crypto-related work. Implementing such a negotiation securely is one of the true challenges in practical cryptography. There is one very profound and fundamental conclusion that can be drawn from looking at the past efforts that involved implementing negotiating the cryptographic algorithms: don't! Instead, mandate one and only one symmetric algorithm. With one and only one key size. It doesn't so much matter which algorithm you chose as long as it is strong crypto. The obvious choice, however, is AES. Now you can chose 128 bit AES or, if you are concerned about quantum cryptanalytical attacks, choose 256 bit AES. But whatever you do, choose one and only one. Then stick with your choice. You will save man years in wasted development and interop effort. > With that out of the way, probably the most exciting think that I am > looking forward to seeing is data modification. There are several > interesting aspects to this: > > - What PKK crypto do we use? Again, chose one for each application and stick with it. RSA tends to be the obvious choice. Ephemeral DH makes sense if you need perfect forward secrecy. Depending on what the PKC is supposed to accomplish and where it is taking place, the choice between RSA and DH will be obvious. [...] > - What form should the updates take? (ie. a simple "replace the entire > data with this / delete the data", or a more sophisticated "diff" style > update). diff is good, though if all the data is encrypted, just replacing the data would make more sense. > Updatable data will open the door to many cool new features, such as > useful hyperlinking, and such-like. > > One thing I was thinking of is placing Java class files on Freenet, so > requesting "com.sun.whatever.Class" will return that class file. Java > could then be hacked to run Java straight off Freenet. Hmm, I must be missing something here. Freenet requires Java to run. So how can you bootstrap by getting your Java off Freenet? -Lucky Green <shamrock at cypherpunks.to> "Among the many misdeeds of British rule in India, history will look upon the Act depriving a whole nation of arms as the blackest." - Mohandas K. Gandhi, An Autobiography, pg 446 http://www.citizensofamerica.org/missing.ram _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
