On Saturday 07 June 2008 07:36, Daniel Cheng wrote: > On Sat, Jun 7, 2008 at 7:46 AM, Matthew Toseland > <toad at amphibian.dyndns.org> wrote: > > On Saturday 07 June 2008 00:06, Matthew Toseland wrote: > >> PROBLEM: > >> If an attacker can identify that each block belongs to the same stream of > >> requests or inserts, he can move towards the originator increasingly > > rapidly: > >> each request gives him a bearing on the direction (in the keyspace) of the > >> originator, and he can use this information to connect to nodes closer to > > the > >> originator. Each time he does this, the amount of the stream that he sees > >> increases, and therefore his search accelerates. This attack is easiest on > >> opennet, but it may also be possible on darknet for some attackers (but much > >> slower!). > >> > >> PARTIAL SOLUTION: > >> We have a partial solution in that we don't insert the top block, or > > generate > >> the key, until after we have inserted all the data below it. However, in > > many > >> instances the data will be guessable (or guessable to within some computible > >> entropy e.g. all but a few bytes) and therefore the attacker can still > >> identify the blocks. > >> > >> BAD SOLUTION: > >> One proposed solution (for inserts) is to insert each splitfile encrypted > > with > >> a random key. This would help a lot with this attack (for inserts), but it > >> would cause much more data duplication, entirely losing the benefits of > >> convergent encryption (CHKs). To what degree convergent encryption is useful > >> is an open question, but there is a better way... > >> > >> NEW PROPOSED SOLUTION: > >> When Alice inserts a file, her node runs FEC encoding as usual. Then a > > random > >> obfuscation key is chosen, and each block is encoded, both with the random > >> obfuscation key, and with the normal CHK convergent encryption. Alice's node > >> inserts only the obfuscated blocks, but it computes the CHKs for the > >> non-obfuscated blocks if they were inserted. > >> > >> The top block includes pointers to the top level of the splitfile for both > > the > >> obfuscated and non-obfuscated versions, but only the obfuscated version has > >> been inserted *by Alice*. > >> > >> Alice announces the key on a public forum. Bob (hopefully there will be many > >> Bob's) starts to download it. For each block in the splitfile, Bob's node > >> tries the non-obfuscated block first, maybe giving it a 3-try head start. > >> Then when this fails it tries the obfuscated block. When each obfuscated > >> block is fetched, there is a chance that the non-obfuscated version will be > >> inserted by Bob's node. > >> > >> Thus, Alice is protected by Bob. Most likely Alice is in the greater danger: > >> generally you want to go for the source of the data. The attacker will then > >> only gain a small amount of information from a splitfile insert: even though > >> he can identify the blocks in retrospect, he can't move towards the insertor > >> during the insert, so he gathers much less information. It will probably > > take > >> more than one splitfile insert to trace Alice. Of course, splitfile inserts > >> aren't the only thing that gives him bearings on Alice's location, her FMS > >> posts etc (e.g. announcing her files) will also betray her in sufficient > >> quantity. It would be good to have some sort of guesstimate that you have to > >> change identity every X messages or inserts to be reasonably safe... > >> > >> Sadly protecting requestors in this way is impossible afaics (although in > > the > >> long term, premix routing and/or tunnels will help). And in the long run we > > Does premix routing solve this problem? Or just make this a little bit > more difficult? > > If can solve this problem, then we may want to defer this until we > have some final discition on premix routing. There is no urgent need > to duplicating this effort.
Premix routing does not fully solve this problem. It will help in that it will only be possible to trace the insert to a premix cell, but that cell will have to be a small subset of the overall network. Even if a cell is 10,000 nodes, if you combine that with some other data (times of inserts maybe), you may be able to get it down to a number of nodes which it is practicable to send the blackshirts to go bust! The two mechanisms operate on different levels. On a darknet, premix routing lets you hide in a (possibly fairly large) cell, constructed from darknet, leveraging the trust network to select non-evil peers; on opennet, premix routing may be more like a traditional onion router such as Tor (more easily subject to Sybil attacks, and possibly observation of tunnel construction depending on how we implement it). Certainly darknet premix routing does not solve the problem. So no, the two systems are complementary. Also, it is highly unlikely that we will implement premix routing this year. It would be a large task, and would not immediately improve performance or usability, so it is out of scope for 0.7.1, given the severe time and money constraints we are facing. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080607/fc96b635/attachment.pgp>
