Matthew Toseland wrote: > 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. > > So if I have enough transistors, resistors, capacitors and soldering wire I'm going to be framed for being able to build [evil thing, you name it here] even IF I HAVE NO INSTRUCTIONS (no formula because of no metadata, no decryption key) and NO CLUE HOW TO DO SO (no guide which blocks to combine how; best fit is bruteforce permutation through all possible XOR combinations) for that?
So if I have, say, 1 ton of Fe, Si and C-elements and a heat source, I could *theoretically* make my own [name of bad thing here] as these could be combined to build this - this is outright stupid. Even more when without instructions. >>> 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 >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Tech mailing list >> Tech at freenetproject.org >> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech