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*. > 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.
