On Friday 12 December 2008 14:54, freenetwork at web.de wrote:
> 
> Matthew Toseland wrote:
> > On Friday 12 December 2008 14:14, freenetwork at web.de wrote:
> >   
> >> I'm sorry if this appeared rude, it really was not intended to be. I
> >> better add that emoticon next time ;)
> >>
> >> Then again, I also had the idea to combine OFFSystem and Freenet.
> >> OFF's chunk size is uniformly 128 KiB and these chunks can be reused
> >> across different contents, so the datastore would boil down into to a
> >> flat heap of simple fragments that become reassembled - rather than
> >> encrypted files it is currently. Using fragment cache for local actions
> >> and fragment store for specialization is also alot like freenet's store
> >> approach.
> >> I think Freenet as network transportation layer, OFF-fragments as
> >> not-inculpatory-ing storage items, FEC for redundancy and CHK/SSK/USK as
> >> metadata that controls filename, mimetype and fragment recombination is
> >> a really nice idea, not?
> >>     
> >
> > As sdiz pointed out, it's unlikely that this would buy very much 
additional 
> > protection. On basic freenet, the chunks are encrypted and you can't 
> > reasonably be expected to know what encrypted data corresponds to what 
actual 
> > data. Except if they try to show that you have *all* the chunks of a 
specific 
> > file and therefore have probably downloaded it, which is possible even 
with 
> > XORing. 
> but a freenet chunk belongs to only one file, whereas a OFF chunk can
> belong to more than one file and ban be used in more than one
> XOR-operation. So having a chunk that gets used in more than one file is
> an additional protection freenet can not offer, as it's not clear for
> what file the chunk is used and if the node downloaded it or got the
> chunk forwarded.
> 
> Then again, OFF chunks a) don't need to be encrypted as they are
> ""random data"" or b) yould be encrypted within the datastore
> nevertheless, which brings us to par with the current freenet implementation
> > Oh and btw, the last chunk DOES carry data derived from the 
> > original - a chunk of the original XORed with two randomly picked chunks. 
> the "topmost" chunk containing the formula to recreate a "usable" file
> out of the many fragments is the critical part. But then again, this
> information will be stored as SSK/etc, therefore to get to this
> information, the user/robot has to request exactly this specific chunk.
> All other chunks are ""random"" and don't hold information that can be
> used for anything (to the outside, inside they can be used to XOR new
> blocks, etc).
> So the only thing that can frame the user is this special chunk -
> everything else can be, in fact, anything. [Maybe seed the store with
> random chunks right after first install, so there's stuff for XOR and
> *truly* unused, and therefore "clean" chunks?]
> And this special chunk is a) XORed in itself from other chunks, b)
> encrypted and can only be c) decrypted with the key, just like SSKs/USKs
> in freenet *right now*.

Whether they are bound to a single file or not, if you have all of them for a 
specific file, you've probably downloaded/uploaded that file recently.

> > And 
> > then there's the question of finding the chunks in a way that doesn't give 
> > away your location, which is not insoluble, but would be a potential 
source 
> > of attacks.
> >   
> seems to me like the usual things that affect "normal freenet" FECcing?
> But as the chunks are not bound to one single file (like FEC block in
> freenet are) this might bring this thing at least a half step further.
> 
> _______________________________________________
> Tech mailing list
> Tech at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 
<https://emu.freenetproject.org/pipermail/tech/attachments/20081212/c4e33358/attachment.pgp>

Reply via email to