[tor-dev] Proposal 188: Bridge Guards and other anti-enumeration defenses

[Roger Dingledine]

On Thu, Oct 20, 2011 at 06:00:20PM +0000, Robert Ransom wrote:
> On 2011-10-20, Nick Mathewson <nickm at torproject.org> wrote:
> 
> > 4.3. Separate bridge-guards and client-guards
> >
> >    In the design above, I specify that bridges should use the same
> >    guard nodes for extending client circuits as they use for their own
> >    circuits.  It's not immediately clear whether this is a good idea
> >    or not.  Having separate sets would seem to make the two kinds of
> >    circuits more easily distinguishable (even though we already assume
> >    they are distinguishable).  Having different sets of guards would
> >    also seem like a way to keep the nodes who guard our own traffic
> >    from learning that we're a bridge... but another set of nodes will
> >    learn that anyway, so it's not clear what we'd gain.
> 
> Any attacker who can extend circuits through a bridge can enumerate
> the set of guard nodes which it routes its clients' circuits through.
> A malicious middle relay can easily determine the set of entry guards
> used by a hidden service, and over time, can determine the set of
> entry guards used by a user with a long-term pseudonym.  If a bridge
> uses the same set of entry guards for its clients' circuits as it does
> for its own, users who operate bridges can be deanonymized quite
> trivially.

I think that's a good reason to have the guards that clients get through
the bridge be different than the guards that the bridge uses for its
own traffic.

I'll also note that this proposal may not be quite as high-priority
as it originally was, if we go the "multi-homed bridges" route: see
the parenthetical note at the bottom of attack #2 on
https://blog.torproject.org/blog/research-problems-ten-ways-discover-tor-bridges

--Roger