On Sunday 30 December 2007 13:19, Michael Rogers wrote: > > >> This could actually be used in place of premix routing: instead of > >> constructing cells we use random "tunnel IDs". > > > > No use against a local attacker. > > What kind of attack do you have in mind?
"Local" = direct peer. If we use one tunnel per local pseudo-identity, it might work, but there is still a very high chance that the node sending the request is the originator. OTOH if we use more than one tunnel, either local collusion or rerouting may make life *much* easier for the attacker. > > > So a local attacker *immediately* knows that the keys are connected. > > Right, but who cares if the attacker knows that? The attacker doesn't > know whether you're the initiator of the tunnel. Makes it easier to track down the origin node for a swarm of requests once it reaches the request stage. Maybe that's not such a big deal. > > > 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... > > The number of tunnels should be kept to a minimum to slow down > predecessor attacks (that's I2P's major weakness: tunnels are rebuilt > too frequently). 100 tunnels will give an attacker as much information > as 100 requests under the current system. > > On the other hand if you use separate tunnels for separate files then > it's harder for an attacker to link them, which makes it harder to use > them in a predecessor attack. So the initiator should choose tunnels > intelligently - eg give each client its own tunnel and each large > splitfile its own tunnel. For performance most users would likely want the node to use multiple tunnels for a single splitfile, and arguably this is a security issue: if the attacker receives the tunnel, and doesn't like its contents, he can trickle-feed it as an effective DoS. Note that an attacker in this case can be any node along the entire tunnel path, because they all know the keys. For premix routing, any effective attack requires that the tunnel exit node is owned by the attacker, and usually at least one node prior to that also. > > > 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. > > True, but the same applies to premix routing: even if there are 100 > nodes in the cell, if you premix for 5 hops there's a 20% chance the > previous hop is the initiator. Misleading. :) If you are the exit node, you know there is a 1/cellSize chance the previous hop is the initiator. You can only know there is a high chance if you control both the exit node and a nonadjacent node before that, and you can tell that both are on the same chain. IMHO we can eliminate covert signalling, and without that all you have is the request timing, which may be enough, but will require a lot of requests to be sure of anything. Much superior to tunneling IMHO. > > > Finally, are there any vulnerabilities in changing paths? > > Yes - churn will force initiators to build new tunnels, speeding up the > predecessor attack. > > > 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. > > Yup, there's no way to prevent predecessor attacks as far as I can tell, > but we can slow them down to one sample per tunnel instead of one sample > per request. -------------- 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/20080103/795d78e5/attachment.pgp>
