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. > > > > > -------------- 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/1e1b599b/attachment.pgp>
