On Friday 21 December 2007 01:08, cbreak wrote: > Matthew Toseland wrote: > > > > That is how it already works. There is nothing wrong with reusing previously > > inserted files, the best way to do it is probably to reinsert only the top > > part of the metadata, inside the container. (We *don't* do that). Referring > > to files via the previous edition is dodgy IMHO as it requires the previous > > edition not fall out, so jSite's compromise of manually inserting big files > > and then feeding in their CHKs is probably pretty close if inconvenient. > > Always inserting every file as a CHK, as pyFreenet does iirc, is bad, because > > it avoids opportunities for containerising, which can save a lot of space. > > Downloading a large file, such as a linux iso, can fail. The usual thing > to do then is to request a reinsert from the original inserter, and then > continuing the download. If every insert is randomly encrypted with a > new key, this will not work. The new file will consist of completely new > blocks, and the file would have to be re-downloaded, even if only one > block is missing.
Yep, and it sucks for ULPRs too. But we make a major class of attacks *much* harder (against inserts), if we make it impossible for an attacker to correlate keys before we announce the key. I was hoping somebody would propose some practical middle ground solution ... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20071221/65148d8f/attachment.pgp>
