> I don`t want to limit myself to 160 bits. I just don`t like limits, > regardless of what calculations you can make at how impossible it is to > reach them.
I agree, and that's why I've never argued for limits, and don't understand why you think I have. I am arguing for using a specific size right now for present purposes; such a size does have to be chosen, and our message format allows for larger ones if needed later, so there really isn't a problem picking one now even if we are sure it _will_ be inadequate later. The advantage of picking a reasonable size now is that unlike some other details of Freenet, Keys are necessary to expose to user-space. A lot of the implemention of Freenet can be hidden behind a client-- but keys can't. Even if most of them are followed in named hyperlinks, many will still have to be cut and pasted from email and other apps, and some are going to have to be typed and/or printed. Since 160 bits already requires 40 characters of hex or 27 of Base64, that's a pretty heave user burden already. We can experiment with encodings that take more characters but are easier to remember and transcribe (as KHKs typed in original English will be), but there's always going to be that much data. > If we are dealing only with KHKs, then 160 bits is too long anyways. KHKs will be typed by the user in original form, and hashed by the system. If you want to use a smaller hash for them, I have no problem with that, but there's no disadvantage to using a full SHA. > But for CHKs the situation is different. The hash that is the key HAS > to be secure - otherwise the data can be faked. Even maliciously > creating duplicates should not be possible. A birthday attack on 160 > bits is only 2^80, and that is not impossible within 20 years for all > we know. Again, it can be expanded if needed, but even to begin such an attack, the first document had to have been inserted and propogated for as long as it took to run the attack; that may well be sufficient for many docs. For example, the plans for the next meeting of the revolution only have to remain up until the meeting. Something like "how to build an h-bomb" will need more security as you point out because we intend a long lifetime for it. If it becomes compromised, there's the advantage that it will be easy to detect and easy to work around: just repost it with some extra whitespace (and therefore new CHK), or create a new longer CHK keytype if really needed. But let's not go there until we need to. -- Lee Daniel Crocker <lee at piclab.com> <http://www.piclab.com/lcrocker.html> "All inventions or works of authorship original to me, herein and past, are placed irrevocably in the public domain, and may be used or modified for any purpose, without permission, attribution, or notification."--LDC _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
