Lee writes: > 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.
DSA signatures are 320 bits long. > 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. This allows the node to decrypt the data as it returns it, because it then has access to the decryption key. Other proposals don't give the node this power, allowing it to be more oblivious to the data contents. Also, calculating the CHK over the unencrypted data makes it impossible for other nodes to check it as it is being returned, unless they decrypt the data as it passes through, which further hurts opaqueness. Hal _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
