Could a client keep the top block available by requesting it lets say once per day? When the MaxSize option is used this could be a cheap request.
On Thu, Apr 23, 2009 at 04:03, Matthew Toseland <toad at amphibian.dyndns.org> 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 > -- __________________________________________________ GnuPG key: (0x48DBFA8A) Keyserver: pgpkeys.pca.dfn.de Fingerprint: 477D F057 1BD4 1AE7 8A54 8679 6690 E2EC 48DB FA8A __________________________________________________
