On Monday 24 March 2008 18:06, Michael Rogers wrote: > Matthew Toseland wrote: > > Given that the attacker can only identify the insertor after the last block is > > inserted, the attacker can still check logs on nodes he controls, after he > > has the top block. These may give him a reasonable fix on the originator > > keyspace wise, however the amount of information is limited by the distance > > between the attacker and the insertor. > > The attacker in your scenario seems to be asking "who inserted/requested > file x", but if the attacker asks "which files did node y > insert/request" then the logging attack is quite effective: the attacker > connects to the node*, and if the node requests a large fraction of any > splitfile then it's probably the original inserter/requester. Simple as > that.
Right. That's a classic correlation attack. If the attacker is a random darknet user who simply wants to see what his peers are doing, or if he is able to connect to every node at once, or a big enough section of the network that he can systematically work his way through it and hopefully catch his target inserting (especially if the target's inserts are large), this is feasible. However, if the network is large and the attacker's capacity for connecting to many nodes at once is limited, or if the attacker needs to trace the originator very quickly, an adaptive search as I have described will be more feasible / yield results much faster. > It doesn't matter whether you insert the top block first or last - > when the attacker learns the top block's key he just needs to check his > logs for the other blocks. (I know you know about this attack already, > but I'm trying to emphasise that a lot depends on which question the > attacker is asking.) Right. > > A powerful attacker might be able to connect to every opennet node > simultaneously, in which case the answers to "which files did node y > insert/request" also answer "who inserted/requested file x". Right. But if the opennet is a million nodes, each of which has an uplink of 100kB/sec and 20 peers (presumably uplink settings being limited by what your ISP will tolerate rather than your actual upstream bandwidth), the attacker will need on the order of 5GB/sec of bandwidth, and some ridiculously large computers to go with it... or a botnet of comparable size to the whole Freenet network. On the other hand, on darknet, each connection may cost a measurable dollar amount, so it would again be expensive even if the network is small. Either way, an adaptive search is much cheaper than a brute force search, although connecting to everyone is tempting if you have the resources. > > > 2. Easy full solution with large cost: > > Encrypt the whole splitfile with a random key, or salt the splitfile > > encryption key(s) with a random key. This should make life very much harder > > for an attacker attempting to trace an insert. The problem is it eliminates > > all space savings from CHK-based splitfiles. This proposal is feasible > > immediately. > > Two questions: > 1) How important is saving space compared to anonymity? A very good question. > 2) How much space is actually saved by convergent encryption? As the paper argues, the space savings may not be very large. However there are special benefits for Freenet e.g. a user may be waiting for a specific file, regularly rerequesting it; if another user happens to have it, it would be good if the first user would find it immediately and not have to pick up the announcement from the second user. Similarly, if a user is able to get most of a file, but not the last 20%, he may ask for it to be reinserted; it would be best if the reinsert doesn't result in a completely new key, but reuses the existing blocks. Obviously a few unusual applications would benefit greatly from convergent encryption (e.g. daily system snapshotting). > To put it > another way, how often are large, identical files independently inserted > by more than one person? I would guess that this is rare, and will > remain rare as long as it's easy for people to find content - nobody > will bother inserting a large file if they know it's already available > on the network. Hopefully. > > But using a random key wouldn't defeat the logging attack, so maybe it's > a moot point. No. IMHO making an adaptive search as hard as possible is important. > > Cheers, > Michael > > * Please don't just say "opennet sucks, use darknet" - everyone is using > opennet and will continue to do so until Freenet reaches critical mass > (if it ever does), so we need to make opennet secure. The above attacks are relevant even on darknet, they're just a lot slower and more expensive. But a sufficiently powerful and motivated attacker might use them against a darknet. An adaptive search is much much cheaper in both the case of a large opennet and the case of a small but hard to penetrate darknet. Connecting to everyone is tempting but expensive even in the latter case, think East Germany! -------------- 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/20080324/a6913017/attachment.pgp>
