Argh, no, this doesn't work, because the pubkey is known, and there is no way for the node to verify that the content is in fact valid. An attacker can not only cause collisions, he can preemptively block known content by inserting bogus data to where it would be posted.
So what does that leave? On Thursday 23 April 2009 01:48:46 Matthew Toseland wrote: > 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. Make cryptokey the hash of the content, avoids different-content attacks. > 2) CHKs with extra routing keys: > CHK@<routing key 1>,<routing key 2>,<routing key 3>,<crypto key>,<extra> Replace crypto key with the hash of the content, and derive the crypto key for each block: cryptokey_N = H ( H(data) + "N" ) 3) Reinserting the top block when a download has finished, and also at some point after inserting the data. IMHO this may help, but it does not address the core problem. We need redundancy over *different areas of the keyspace*. 4) An FCP command to reinsert a file, given a known top-block key. If we cannot reconstruct as-is, we fail, but if we can, we reinsert that block (exactly as is, like a binary blob), and the rest of the CHK-based blocks under it. Maybe a combination of 1) and 4) ? On first insert: User inserts the data as DSK,3@/filename. The node creates a random pubkey, and hashes the content of the top block to get the cryptokey. It inserts each block, and returns DSK,3@<pubkey>,<cryptokey>,<extra>/filename The filename could be ignored if we want. On reinsert: The original URI must be specified, and have been downloaded. If it is kept on the download queue then we can simply click a button to reinsert. For SSKs: User inserts the data as SSK,3@<privkey>,<cryptokey>,<extra>/<filename> We insert to SSK@<pubkey>,<cryptokey>,<extra>/<filename>-<N> for N in 0, 1, 2. Since the URI is not content-derived, there is the possibility of the inserter will insert different content to each slot. AFAICS this cannot be avoided. The major disadvantages are: - When reinserting we MUST know the original URI. - There is no way to heal the alternate top-blocks. IMHO the latter is more serious than the former, but full convergence would be ideal. Option 2 has neither of these problems, but does have very long URIs. Mostly keys are copied and pasted, so maybe that isn't a big problem? If people are happy with option 2 (very long CHKs), I can implement it reasonably quickly... > > 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/2f28e9a3/attachment.pgp>
