[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #8163 [Core Tor/Tor]: It is no longer deterministic which Sybils we omit



#8163: It is no longer deterministic which Sybils we omit
-------------------------------------------------+-------------------------
 Reporter:  arma                                 |          Owner:  (none)
     Type:  defect                               |         Status:  new
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  unspecified
Component:  Core Tor/Tor                         |        Version:  Tor:
                                                 |  0.2.4.10-alpha
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-dirauth sybil voting needs-spec  |  Actual Points:
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by teor):

 Replying to [comment:24 arma]:
 > So, I think an evil person could manipulate which dir auths it responds
 to, to get a 2x increase in Sybils per IP address. But I think it's capped
 at 2x, because we demand a majority of Running votes from each dir auth to
 put you in the consensus.

 It's strictly less than 2x.

 With AuthDirMaxServersPerAddr 2:
 * there are 9*2 = 18 Running-votes per IPv4 address
 * a majority is 5/9
 * 18/5 = 3

 With AuthDirMaxServersPerAddr 4:
 * there are 9*4 = 36 Running-votes per IPv4 address
 * a majority is 5/9
 * 36/5 = 7

 3 extra relays is a significant jump from 1 extra relay.

 Maybe we should fix this bug by adding a tie-breaker to the comparison?

 If we want the "best" relays, and we want convergent behaviour, we should
 sort by Running, weighted fractional uptime, then fingerprint to break
 zero-uptime ties.

 But it's still possible to game those checks, so we should:
 * add AuthDirMaxServersPerAddr as a consensus parameter, hard-coded to the
 value of the AuthDirMaxServersPerAddr torrc option
 * add a new consensus method that only chooses the first
 AuthDirMaxServersPerAddr relays per IP address, sorting by Running, then
 fingerprint

 These bugs shouldn't be that hard to fix.

 Do we have a sponsor for it?
 It fits within the broad topic of Sponsor V, but it's not in scope for any
 of the deliverables.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/8163#comment:25>
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