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
