On Mon, Nov 07, 2005 at 03:24:12PM +0000, Henry Gomersall wrote: > I have been thinking for a while now about a method of creating > a deniable p2p network, that is still (of the order of) the > same speed as conventional open p2p networks. What follows is > the result of this thought process.
Most things have been suggested before... but lets have a look. > > Apologies if this is obviously trivial and pointless ;) > > This network would allow a user to upload a file. The file is converted > to pieces and these pieces are what reside on peers' machines. Any > given piece on a users machine can be a component in ANY file in the > network. That is, it can be a component in an arbitrary number of files. Okay, so if I upload a 660MB file, I FEC it into a 1GB file, then I find 1GB of pre-existing content, put that in the manifest, then XOR the real data with it and put that in as well, and insert that. That's what you are talking about here, correct? Lets ignore the issues with finding random content to XOR with, for now (this might be a problem). > This is where the deniability comes in. If a data chunk can be a > component in hundreds of entirely different files, then how can the > uploader be liable. Not only that, but the data is random. It has no > meaning by itself. Only when combined as part of a chain can it be > rendered into the original file. The only draw back of the whole system > is that the user is required to download twice the total data. This is > possibly offset by the potential gains in total file availability, > allowing users to host pieces that can be part of many files. I'm not convinced. The reason: Half the files you use will be already extant on the network. BUT the other half, the half which you actually insert, will be the XOR of the data to be inserted and the preexisting data. Now, given enough time, these will themselves be reused. It does give some robustness, in that you can't attack a single key without it causing collateral damage, but that is not going to be a very strong effect as the files are distributed randomly. You can make arguments on deniability... but basically as far as I can see there are three options: 1. You are liable by running Freenet, which can be and is used to distribute illegal content. Solution: darknet. 2. You are liable by caching illegal content, despite the fact that it would be very difficult for you to determine this; impossible in many cases. Solution: darknet, or better defence lawyers! Generally posession requires knowledge; if there's a bag of drugs in my car, which I just bought from a shady second hand dealer, left by the previous owner, it's not legally my fault - unless I discover it and do nothing about it. 3. You are liable because you fetched illegal content, and it is cached in your datastore because you fetched it. Solution: Don't cache locally fetched content. This is an option in 0.7. The problem is that if a node sees you fetch illegal content, and then probes your store and sees you didn't catch it, it knows it was a local request. This may not be an immediate problem on darknets though. Ultimately the solution is premix routing (freenet 0.8/0.9), but there are some stop-gaps (e.g. random, fixed routing paths with no caching for the first N hops) which offer relatively small anonymity sets. > > The operation of this network is described as follows: > 1) Alice wishes to place a file on the network (file A). This is the > first file to be added to the network: > a) Firstly she splits the file into many equisized pieces. > b) She then generates random blocks of data, the same size > as the pieces of the original file, these are called > r1, r2, ..., rn I thought she was going to re-use random already-inserted blocks from the network? > c) She then logically places alternately a random piece and > a file piece in order as follows: > r1|A1|r2|A2|...|rn|An > d) Using a random start piece (C), a chain is built up by performing > a one time pad on the next data chunk and the result of the > previous one time pad as follows (there appears to be no ascii xor > symbol, so I used a + instead): > > C -> + -> S1 -> + -> Q1 -> + -> S2 -> + -> Q2 -> + ... + -> Qn > ^ ^ ^ ^ ^ ^ > r1 A1 r2 A2 r3 An Hmmm, I see: For the first block, you need r1 ^ A1. For the second block, you need r1 ^ A1 ^ r2 ^ A2. Okay, this is a nice addition to what I was thinking of, but you still need a manifest file. > > e) r and Q are now the data chunks that are shared on the network > f) Each data chunk points to the next but one data chunk in the chain > resulting in the inability of a holder of any arbitrary chunk to > reconstruct the whole chain. C points to the first 2 chunks > resulting in both offset chains being available (perhaps 2 random > start pieces are required - C1 and C2 - so that they look identical > to all other chunks in the network - I haven't really thought > deeply about this). I don't understand. Is it the following: Alice splits file into a1...aN. Alice generates or finds random blocks r1...rN. Alice creates blocks b1...bN by XORing r1...rN with a1...aN. Alice inserts b1...bN, and inserts manifest including b1...bN and r1...rN (randomly swapped of course). ?? > > 2) Bob wishes to place a file on the network (file B). He does this > using the same procedure as Alice, only instead of using random data > for r1, r2, ..., rn, he uses r and Q chunks that ALREADY exist on the > network. That is, the chunks on the network become integrated into > the chain that makes up file B. Okay. > > 3) We now have 2 files on the network that are inextricably linked. They > *are* the same pieces of data. These 2 can be extended to any > arbitrary number of files. The more files, the more cross over occurs > and the better the deniability. Sure, but the greater the cost. If we use 15 random blocks, and 1 real-content-xored-with-all-the-random-blocks block, for each original block in the (fec encoded) splitfile, (we can then either randomize each group of 16 blocks, or just store them in key order in the manifest), then we have a factor of 16 overhead on insert and request. > > 4) Now Charlie wishes to download a file from the network. Charlie > acquires C chunk with a unique key, perhaps from freenet or a friend > or a website. He can now construct the chain intially by traversing > an example of every data chunk and finding where that key takes him. > He can now identify every chunk that is required to rebuild the chain > and hence get back to the original file (it is trivial to work > backwards from all r, Q and C to the original file). All this would > require some kind of distributed tracking system. This certainly is > not my strength, but i have some ideas. Hmmm. So it's some kind of linked list? Ah, this is what has confused me. Previous and current work uses a separate "splitfile manifest", which is metadata which specifies the CHK of every block in the splitfile. The splitfile manifest will be much smaller than the file, but it may itself have to be split. It will also be far more popular than the individual file chunks, so there should be no difficulty fetching it. > > The net effect, as mentioned earlier, is that every chunk downloaded > cannot be said to be definitively a component in any file. Not true. If the attacker can identify which block of each group was already on the network, then he can show that the other block is recently generated. In fact, if he sees the actual insert in progress (due to having a node), he can tell simply by the fact that you only insert the new content. And for requests, you can still do correlation attacks. But it does help for seized-datastore analysis, at a rather substantial cost. I don't think it makes much difference legally though. Oh and you can't optimize by using content already in your store, as this gives a massive amount of information away to an attacker. And on a mature network, your store's 200GB is negligible, so in general you will have to fetch all the blocks. > > I'd appreciate some feedback on this. I feel very sure that there is at > least some potential in some kind of chained set of one time pads (like > above). > > Thanks, > > hen -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so.
signature.asc
Description: Digital signature
_______________________________________________ chat mailing list chat@freenetproject.org Archived: http://news.gmane.org/gmane.network.freenet.general Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/chat Or mailto:[EMAIL PROTECTED]
