[tor-dev] Defending against guard discovery attacks by pinning middle nodes

A. Johnson aaron.m.johnson at nrl.navy.mil
Thu Nov 13 00:55:44 UTC 2014

>> As I was saying above, a fixed exit would allow compromise in the time
>> it takes to begin surveillance (times three). We can likely do better
>> than that.
> Ok, this was my assumption behind arguing for staggering these rotation
> periods, too. I don't think that having a fixed exit is a good idea, and
> this same conclusion has led me to believe that the rotation times
> should be staggered. I am having a hard time understanding why two
> layers of guards of the same rotation lifespan is necessarily better
> than one, especially since the sybil attack to determine the second
> guard from a fast rotating exit is likely to succeed within a few days.

Here are some benefits from two (or more!) layers of long-lived guards:
  1. The adversary has to perform two rounds of installing surveillance and detecting the next hop. This costs him time and money. It also makes it more likely that one of the guards expires or the HS relocates in the meantime.
  2. It increases the chance the one of the guards is in a location that doesn’t cooperate or that the surveillance effort just happens to take longer than the median.
  3. It increases the chance that some node operator gets tipped off to the surveillance.
  4. If there is any chance of a false positive at any hop (unclear to me, depending on how the next hop is detected), this would increase the overall chance that the adversary gets sent down the wrong path.

> I willl try to find some time to play with your script to see if I can
> fully convince myself that rotation doesn't help for the middle node
> even under a coercive threat model.

I think that in the attack model we’ve been discussing, the second hop rotation speed doesn’t affect things much as long as it is, say, an order of magnitude slower than the third hop’s rotation speed and slower than surveillance speed. Then the adversary is much more likely to be chosen as third hop and then perform two surveillance attacks than he is to be chosen is the second hop and perform one surveillance attack. And actually the same argument is true for setting the rotation speed of first hop. However, as I said in a separate email, I now can see a reason to increase rotation speed with each hop from the HS: you don’t actually know surveillance speed (or the fraction of adversarial relays, for that matter), and a sequence of increasing rotation speeds helps you defend pretty well against the full range of possibilities.

BTW, new script attached (also available at <https://github.com/ohmygodel/hs-guard-selection.git>). This one allows you to set the number of guards at each hop from the HS by setting them in the num_guards list.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: hs_guard_attack.py
Type: text/x-python-script
Size: 4284 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20141112/b5598e99/attachment.bin>

More information about the tor-dev mailing list