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>