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

[A. Johnson]

By the way, I actually can think of a good reason to include multiple rotation speeds: to deal with both your uncertainty about surveillance speed and its randomness. Suppose that you think it takes somewhere between 3 hours and 1 month, but don’t have a much better guess than that. Then a good idea might be to have a different relay rotation at a different timescale, say one every 3 hours, one every 3 days, one every 10 weeks, and an entry guard for many months (yes, I realize that is four relays just on the HS side…). Then you can protect pretty well against a range of possible speeds, instead of making it fragile to the possibility that your rotation speed is *just* slower than what would have stymied the adversary.

Aaron

On Nov 11, 2014, at 7:22 PM, A. Johnson <aaron.m.johnson at nrl.navy.mil> wrote:

> 
>> HS -> Guard_1 -> Guard_2 -> Guard_3 -> RP.
>> 
>> The idea is that Guard_1 is a single node that you choose and keep for
>> O(6 months, or as long as possible), but Guard_2 actually comes from a
>> set of 3-6 or so nodes that you keep for O(weeks), and Guard_3 you
>> rotate something like O(hours).
> ...
>> The hope behind my reasoning is that if it is incredibly likely for you
>> to rotate your guard(s) before they are discovered, guard discovery
>> attacks lose their value.
> 
> This doesn’t make sense - do you mean "if it is likely for you to rotate your guards *after” they are discovered"?
> 
>> OTOH, perhaps I am reasoning about this wrong, and it is operationally
>> better to stick with a guard node in the second position for as long as
>> you stick with your first guard. In my mind, having identical rotation
>> periods is only better if you subscribe to the theory that compromising
>> a node is a noisy process, and unlikely to succeed in repeated
>> succession. In which case, you probably just want a static route of
>> exactly three (and only three) guard nodes, fixed for the lifetime of
>> your HS. At least, if you want the most security in this threat model.
>> 
>> Does this make sense?
> 
> I don’t follow your reasoning. Even if compromising is a completely deterministic process, it would be better to have one quickly rotating node at the end of the HS-side circuit because if each hop rotated slowly the adversary would have enough time upon discovery of each hop to set up surveillance of the next (where the last hop is always immediately discovered by the adversarially-chosen RP). Having a quickly-rotating final hop from the HS means the adversary has to wait until the HS rotates to an adversarially-controlled relay.
> 
>> Do you subscribe to the "it's cumbersome and noisy to compromise a node
>> (and therefore you should sit on your routes as long as possible until
>> they break)" threat model, or the "it's likely quiet and/or quick (and
>> therefore all we can do is try to improve the statistics to reduce the
>> likelihood of compromise early in the rotation period)" threat model? Or
>> is there an additional threat model/goal we should be aiming to satisfy
>> here?
> 
> I do actually suspect that it's cumbersome and noisy, but the solution I have argued for doesn’t depend on that (indeed, it is based on a deterministic compromise model).
> 
>> It sounds like you subscribe to the first "it's cumbersome to compromise
>> a node, so keep a fixed route" threat model and goal, right? Would it
>> make you more nervous if the exit was also fixed? If so, why? If not,
>> why not?
> 
> 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.
> 
> Aaron
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev