On Thu, Apr 23, 2009 at 8:48 AM, Matthew Toseland <toad at amphibian.dyndns.org> wrote: > I would really appreciate input on option 2 i.e. how much of a problem are > long CHKs? > > On Thursday 23 April 2009 03:03:00 Matthew Toseland wrote: >> 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. >> > >> >> >> > > > > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl >
Extra long CHK's are no problem at all. As many have pointed out, we all just cut and paste or clink a link. I say go for it. Option 2 with option 3 would make me very happy. -- I may disagree with what you have to say, but I shall defend, to the death, your right to say it. - Voltaire Those who would give up Liberty, to purchase temporary Safety, deserve neither Liberty nor Safety. - Ben Franklin
