[tor-dev] Setting NumEntryGuards=2

[George Kadianakis]

Mike Perry <mikeperry at 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-parameters
> 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:
>
> 1. 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!