On Friday 04 January 2008 19:35, Michael Rogers wrote: > Matthew Toseland wrote: > > - The tunnel length is likely to be shorter than the routing length. So > > P(predecessor = originator) drops from 1/routing length to 1/tunnel length - > > say 1 in 15 down to 1 in 5. > > True, the tunnels would have to be quite long. On the other hand we > don't know how much information the hop counter and > closest-location-so-far are currently revealing, so it's possible an > attacker has a better than 1 in 15 chance of identifying the initiator > during the routing phase. (For example, if the hop counter isn't MAX or > MAX-1 then the previous hop can't be the initiator, right?)
Hmmm. That's true. So it may even be an improvement. Probe data can show how often we reset, but lets assume we reset 3 times (this is an ideal, in practice IIRC we reset more often than that). The 50% chance of decrementing at 10 means that 3 resets equals 6 nodes with HTL 10... When an attacker gets a tunneled request, he knows 1) there is a 20% chance that the node is the originator, and 2) that he is close to the originator, because he is early on the route: the tunnel is only active at the beginning. For a regular request, the HTL can be 10 much later on in the request. In which case the predecessor sample is useless, and the key is likely close to the location of the attacker. Is this a plus or a minus for tunnels? Somewhere on this thread you said that the probability of two related tunnels coming from the same node is independant of that node being the originator. I don't understand that. > > > Yes, but a clever attacker can reconstruct the topology for a few hops without > > too much difficulty. It's messy, I haven't come up with a good algorithm yet, > > but I haven't really tried: there should be one. > > Good point, we should be pessimistic. > > Cheers, > Michael -------------- 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/20080104/453dfdea/attachment.pgp>
