A. Johnson: > > > 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"? Err, right, my argument for the different rotation periods hinges on minimizing the time after discovery happens during which the adversary gets to try to set up surveillance. > > 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. > > > 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. 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. However, I also see that if we're talking about those middle nodes rotating on the order of a week, that might be a long time for an adversary to play with to determine the first guard, even if we minimize that expected time period between discovering it and rotation. I guess it depends on what we expect that overlap to be, but it probably is O(rotation_time/2) given that we're dealing with uniform disributions over time here. 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. -- Mike Perry
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev