On Wednesday 29 April 2009 23:12:09 bbackde at googlemail.com wrote: > 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.
No. It might help if it was from a different location on the network each time, but this would require something resembling tunnels, which we don't have yet. Right now it would just ensure that your node cached it, and if you told it to ignore the local datastore, that your nearest neighbour to the key cached it. Further, this does not solve the fundamental problem, which is that data will fall out of caches quickly, and is only stored on 3 nodes, and there's a good chance of all 3 of them being offline, or having left, at the time of the fetch. Although we do try to deal with this to some degree by ignoring low uptime nodes when calculating whether we are a sink ( = whether to store an insert in the store). Another issue is tolerance of weakness in specific areas of the keyspace. We have redundancy for lower down blocks, it makes sense to have redundancy for the top block. Is the length of a DHK a problem? > > 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 > __________________________________________________ > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > -------------- 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/20090430/e3761f0b/attachment.pgp>
