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
>>>
... freenet not only as a network layer but also as a darknet/opennet
infrastructure on peer establishment (friends, strangers), management,
message routing, network topology, etc.
>>> 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.
>
not only it has to retrieve this chunk (of course), but a) this chunk
can be used for other XORing fragments, so this spreads it even further
(some sort of created redundancy) but b) the user/robot has the
decryption key that is needed to decrypt the recombinded chunk to
extract the metadata that holds the formula for the file. Therefore the
critical part is only the decryption key, just like it's in freenet now,
and that key is not part of the data or metadata, but sorely stored in
the file URI, just like in freenet. So we don't lose anything here but
gain some more "onion skins" that provide the user/robot with protection
until the decryption of the metadata chunk. And this has to be done
deliberately by the requesting user, whereas this protects all other
nodes as they can't access anything of this.
> 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.
>
>
So enhancing the "network file representation" by adding a layer of
XORification, we lose nothing but enhance the deniability and protection
of users that request and don't request files/documents. This also
streamlines the storage as the network will only shove 128 KiB fragments
that are used at a elevated level that interprets these to file chunks,
whereas now the network is shoving chunks that are directly associated
to a file.
