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 <[email protected]> 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 > [email protected] > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
