On Thursday 20 December 2007 02:00, Juiceman wrote:
> On Dec 19, 2007 6:19 PM, Matthew Toseland <toad at amphibian.dyndns.org> 
> wrote:
> > [ snip long security argument ]
> >
> > PROPOSAL:
> > Before we encode any splitfile we should encrypt the whole thing with a 
random
> > key. The big advantage is that an attacker will not be able to predict the
> > keys being inserted, even if he knows what data is to be inserted. 
Obviously
> > this depends on us not calculating the key until we have inserted all the
> > rest of the file etc (the first proposal).
> > PROBLEMS:
> > One great thing about Freenet is that CHKs collide: if two people insert 
the
> > same content as CHK@ with the same metadata they get the same key, if they
> > insert the same content with different metadata we still reuse the
> > sub-blocks. This would ruin that. Is it worth it? Is there any safe 
mechanism
> > we can build to enable re-use of inserted data even with this randomised
> > encryption?
> 
> How would this affect Freesite inserts?  If most of the files on a
> Freesite haven't changed are we going to end up inserting and
> retrieving the whole thing for every update, or is this how it already
> works?

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

Reply via email to