It has recently come to our attention that the problem with data persistence is usually that the top block has fallen out or that the few nodes with the block are never online at the same time as the person who wants to fetch it. Hence we need to duplicate the top block. So far there have been two schemes: 1) Duplicate the top block with SSKs: SSK,3@<pubkey>,<cryptokey>,<extra>/<filename> would insert e.g. SSK@<pubkey>,<cryptokey>,<extra>/<filename>-N for a series of N's. 2) CHKs with extra routing keys: CHK@<routing key 1>,<routing key 2>,<routing key 3>,<crypto key>,<extra>
Neither of these schemes is acceptable IMHO. The former allows for an attacker to insert different content to different keys, and get some info about targets that way, and it is non-convergent, not allowing for reinserts. The latter doubles the length of the already way too long CHKs. I propose a new key type which is convergent, has URIs shorter than existing CHKs, and any number of duplicate blocks: the Content Multiplication Key (for want of a better name, alternatives are welcome). DETAILS: Insert the splitfile normally, except for the top block. The top block must fit inside a 1KB SSK payload. Hash the content of the top block: hash of content: H(data) Create a private key: privkey = MAKE_PRIVKEY ( H ( H(data) + "0" ) ) Create the base crypto key: ckey_base = H ( H ( data + "1" ) ) Create a series of crypto keys: ckey_N = H ( ckey_base + "N" ) Insert to a series of SSKs: SSK@<privkey>,<ckey_N>,<extra> Announce the key: UMK,N@<H(data)>,<extra>/<filename> (Where N is the number of copies inserted) The filename is ignored. This will make the Frost folk happy. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090423/18abc534/attachment.pgp>
