Re: [tor-bugs] #9273 [Tor]: Brainstorm tradeoffs from moving to 2 (or even 1) guards

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#9273: Brainstorm tradeoffs from moving to 2 (or even 1) guards
-------------------------------------------------------+--------------------
 Reporter:  arma                                       |          Owner:                    
     Type:  project                                    |         Status:  new               
 Priority:  major                                      |      Milestone:  Tor: 0.2.5.x-final
Component:  Tor                                        |        Version:                    
 Keywords:  tor-client design analysis needs-proposal  |         Parent:                    
   Points:                                             |   Actualpoints:                    
-------------------------------------------------------+--------------------
Changes (by nickm):

  * keywords:  tor-client design analysis => tor-client design analysis
               needs-proposal


Comment:

 I think that when Paul and Mike and Roger all agree, it's probably a good
 idea to move this way in 0.2.5.

 This needs a proposal.

 So, here are some tradeoffs to consider:
   * We need to make sure that the probability of choosing any given guard
 has a lower bound.  If there are some guards that people pick with very
 small probability, that guard's users are going to stand out!
   * In practice, no guard's uptime is going to be 100%.  So in reality,
 even in a 1-guard scenario people will have a primary guard, and a
 fallback guard that they use whenever that guard's down, and a fallback
 fallback guard, and so on.  This means that fingerprinting based on
 complex guard sets will still be possible in the long term.
   * One idea we floated a while ago was deterministic guard grouping.
 Under this idea, you could ''still'' have k guards out of N possible guard
 nodes, but instead of there being N-choose-k possible groups of three to
 choose, there would only be N/k possible choices.
      * The guards would be put into groups by the authorities as part of
 the voting algorithm.  These groups would probably want to be persistent
 somehow.
      * The advantages of this approach are:
         * You'd still get the reliability boost of multiple guards.
         * You'd avoid the "Fallback guard" problem noted above.
         * The fingerprinting opportunity would be limited, even more so
 than in the case where every user picks a node at random.
      * Intuitively, you might think that an attacker would want to
 manipulate the group-assignment process to get there to be groups full of
 completely attacker-controlled nodes.  But I think that the rational
 behavior for the attacker would be to try to spread their nodes out among
 as many groups as possible.
         * It seems hard to prevent an attacker from manipulating a group
 assignment process, especially if groups are persistent over time and the
 attacker can take down old nodes and bring them back up with new
 identity/location.
         * So we should probably try to design a solid group assignment
 process, but we probably want to do our analysis here under the assumption
 that the attacker can manipulate the node selection process, and limit our
 worst-case scenario there.
      * On superficial analysis, I still like this "guard group" idea.
    * Probably we will need equations to analyze specific proposals here.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9273#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs