Mike Perry mikeperry@torproject.org writes:
[ text/plain ] Back in 2014, Tor moved from three guard nodes to one guard node: https://blog.torproject.org/improving-tors-anonymity-changing-guard-paramete... https://trac.torproject.org/projects/tor/ticket/12206
We made this change primarily to limit points of observability of entry into the Tor network for clients and onion services, as well as to reduce the ability of an adversary to track clients as they move from one internet connection to another by their choice of guards.
At the time, I was in favor of two entry guards but did not have a strong preference, and we ended up choosing one guard. After seeing various consequences of using only one entry guard, I think a much stronger case can now be made for bumping back up to two.
Roger suggested that I enumerate the pros and cons of this increase on this mailing list, so we can discuss and consider this switch. So here is my attempt at that list. Let's start with a more in-depth recap of the one-guard arguments, along with some recent observations that change things.
Arguments for staying with just one guard:
- One guard means less observability.
Hello!
Here is some small analysis of Sybil resistance on 1-guard vs 2-guards.
I think this analysis is important even given the #14917 issue, since we could defend against that by lifting those particular path restrictions. I agree that's not ideal, but IMO it's definitely something we should consider as part of a thorough analysis, since by solving #14917 correctly we could still maintain connection to just 1-guard (assuming it's a stable node).
===
So on to Sybil resistance analysis:
For a 5% bandwidth adversary and a single guard, an attacker would have 50% chance to Sybil your G1 (i.e. deanonymize you) after 14 rotations. For a 3.5 month rotation frequency, this means that you would expect your guard to be uncompromised by Sybil's for about 4 years. For a 10% adversary you need 7 rotations for 50% so that's 2 years.
Now if we go to two guards, a 5% adversary would need 2 years to Sybil your G1, wheras a 10% adversary could do that in 1 year.
All the above numbers are assuming a completely stable guard node, that you only switch because its lifetime expired and not because of reachability issues etc. So in the real world, the actual guarantees are probably lower.
In general, I obviously feel more comfortable with the single guard results, but also the dual-guard results are not so bad.
===
Now with regards to engineering, here is also something to be said about how the prop271 algorithm will handle NumEntryGuards=2:
IIRC, the way it's currently handled means that if any of the two first primary guards is down, the algorithm will skip that and choose between the two next available, potentially going into the third primary guard in the list [see how select_entry_guard_for_circuit() uses get_n_primary_guards_to_use()]. This might not be ideal, and perhaps we should tolerate some small unstabilities of the primary guards so that we don't get to expose ourselves to even more guards...
Also, we need to look at how guard_selection_get_err_str_if_dir_info_missing() will work after we increase NumEntryGuards, since that function is what caused #21969, and we should make sure that it's not gonna get more annoying if we bump up the number of guards.
That's it for now! :)
Cheers!