All keys are not 160 bits. That is not a limitation I am willing to accept, keys should be of generic length, limited only by whatever length we limit fields to.
The data is not encrypted by the Freenet key in the case of the CHK data, because the CHK can only be calculated after the data is encrypted. Instead, the CHK must be encrypted by another key, and that key must be distributed together with the CHK. One way of doing this could be: 1) Hash the plaintext data 2) Encrypt the data with the hash from 1 (or n first bits of it) as the key. 3) Take hash of cyphertext, use as CHK The CHK must be a hash of the Cyphertext so that nodes can validate it without having to decrypt the data. The reason to use the hash of the plaintext as the encryption key would be to avoid people inserting the identical document under two different CHKs because they chose different keys when they encrypted it (this only needs to be convention). Because each encryption key is used only once, and only for that data, using the hash should not be a security issue. The encryption key (hash of the plaintext) still needs to be distributed with the CHK in all links etc, of course. Regarding whether new keytypes require new message types, of course they don't. The behaviour of the messages is the same, the only difference is how the key is validated (for KHKs it is always valid, for CHKs it needs to be a hash of the data, for SVKs it needs to validate a signature, etc). Ian and Brandon do not believe this however (no, I never understood why), and I got tired of debating it with them. On Sun, 23 Apr 2000, Lee Daniel Crocker wrote: > Here's a specific way to implement Keys that allows all > types, but needs no new messages, applies key-hashed data > to all types, and can be implemented flexibly. > > All keys, of any type, are 160-bit numbers with a > 16-bit keytype value, so keyspace is 176 bits. KHKs > are made by applying SHA to a text name; CHKs by > applying SHA to the Document (including the metadata > section, if any); SVKs by digitally signing a KHK > with DSA. > > After these 176 bits are created, the document is > encrypted using them as a key with something like > Twofish. Insert requests carry the 176-bit key and > the data. When the data is placed into the data store, > the node saves the data but saves only a further hash > of the original key. In the process of storing, they > can verify signatures and content hashes. The > inserting node can also, if it desires, retain the > 16 key-type bits and use those to partition its > data store or for other functions as Brandon thinks > it might--but that's a decision each node can make for > its own reasons and plays no part in the protocol proper. > A node should NOT retain the original 160 bits of > "real" key so that examination of its data store will > not reveal any information. > > Data Requests carry the full 176-bit key. Each node, > upon receiving a request, hashes the request key in > the same way it hashed the keys it stored, compares > with all of them regardless of type. On a match, it > returns the encrypted data, which the receiver must > decrypt with his original 176-bit key. In the > astronomically rare event that two keys hash to the > same value, this decryption will fail, advising the > user of the error. There's no way to avoid this, and > the odds are too small to worry about. > > Is there any obvious flaw I'm missing here? > > -- > 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 -- Oskar Sandberg md98-osa at nada.kth.se #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1 lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/) _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
