On Friday 21 December 2007 02:01, Matthew Toseland wrote: > 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.
This is true, but unduly pessimistic: the attacker can only approach you if he first can correlate different tunnels, and secondly is either on the tunnel, or manages to trace back until he reaches the tunnel. And there is a difference in quantity: Whereas right now, he can trace you from every request, with tunnels, he can trace you from every tunnel. Of course there are active attacks he can do with a long lived tunnel that he can't do with a request: temporarily block each node connected to a known tunnel member in turn, and see which one causes the tunnel to fail, for example (to stutter rather than fail, if we are using a location based tunnel, but still, it's detectable). We can't send all the URIs up front to prevent this as we'd open up lots of very interesting DoS possibilities. We can't stop it when we unexpectedly lose a connection either, as again we have to make the requests at approximately the same rate we are able to send them on at, so causing packet loss would be just as good an attack. And this doesn't rule out exotic attacks such as root'ing each node along the chain as they transfer the data, but neither can anything else, and if the attacker is able to do that he can probably turn the whole network into a surveillance system for catching you. :) Nonetheless, a major improvement.. especially if we start the tunnels at the edge of a premix cell. -------------- 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/c38fde30/attachment.pgp>
