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

Reply via email to