On Friday 21 December 2007 00:25, Matthew Toseland wrote: > > Messages belonging to the > > same splitfile are marked by their initiator with the same tunnel ID. > > So a local attacker *immediately* knows that the keys are connected. And so > does a remote attacker if they leak long distance, which they will especially > with probabilistic termination. > > > During the random phase, each hop chooses the next hop or switches to > > greedy forwarding pseudo-randomly based on the tunnel ID, so messages > > with the same tunnel ID follow the same pseudo-random path and switch to > > greedy forwarding at the same point. > > This has been proposed before. One weakness is you'd need more than one tunnel > to get good or predictable performance. And as soon as you have multiple > correlatable or identical tunnels from the same node, it gets really easy to > identify the requestor - admittedly it may require a conspiracy... Am I wrong > here? That was always my analysis before, but by all means poke holes in it, > I'd love to implement something simple! > > Also, you have a very small anonymity set: if the tunnel is on average 5 hops > long, there is a 20% chance that the node that sent you the request is the > originator. This is unacceptable, especially if you can correlate the 20%'s > because of linked but non-identical tunnels.
Okay, so you bundle after you exit the premix routing cell. The problem then is that if the attacker can correlate different splitfiles over time, he can get closer to the premix cell. Very slowly, hopefully. You could use a single persistent identity, but the problem with that is that you are explicitly declaring the requests to be connected which might be exactly what the attacker wants to know, and it makes intersection attacks easy. > > Finally, are there any vulnerabilities in changing paths? > > > Thus no predecessor attacks are > > possible during the random phase. Predecessor attacks during the greedy > > phase will lead the attacker to the last hop of the random phase, which > > will provide no information about the location of the initiator if the > > number of random hops is sufficient. > > Indeed, random hops seem to be the way forward. But if you get the request > during the random hop phase, you can attack the originator, although it will > take much more time than without random hops. > > > > Tunnels will sometimes break due to churn, but the same can happen with > > cells - no matter what system we use, churn will always allow > > predecessor attacks because it forces initiators to choose new paths. > > The idea was to pick two random nodes from within the cell, and route through > them - choosing a new tunnel for every request. When a node goes down, we get > notified pretty quickly, since we're in the same cell. Our anonymity set is > the cell, and nodes only move between cells by cells splitting when they get > too big. The one big weakness is that cells would have to be relatively small > to keep global data available. The complication (IMHO solvable) is bogus > topology attacks. > > > > Cheers, > > Michael > > > > [1] http://www.crhc.uiuc.edu/~nikita/papers/phd-thesis.pdf > > [2] http://iptps03.cs.berkeley.edu/final-papers/koorde.ps > -------------- 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/20071221/e6cc21dd/attachment.pgp>
