Re: [tor-dev] entry guards and linkability

[Nick Mathewson <nickm@xxxxxxxxxxxx>]

On Wed, Sep 11, 2013 at 10:57 AM, Leif Ryge <leif@xxxxxxxxxxxxx> wrote:
> Is the following statement correct?
>
> When a user connects to Tor from multiple locations where the network is
> monitored by the same adversary, their persistent use of the same set of entry
> guards uniquely identifies them and reveals their location to the adversary.

To avoid confusion, I would phrase that as not as "reveals their
location to the adversary" but as "shows the adversary that
connections are all coming from the same user."  But yes.

(If you want to avoid this, you also need to make sure that your MAC
address is randomized whenever you move networks, that you make
absolutely no non-Tor connections, and so on.)

> Assuming this is an accurate assessment, wouldn't it make sense to maintain
> separate sets of entry guards for each network that the user connects from?

This is indeed a desirable feature, I think, although you'd want to be
quite careful in how you tell what a "network" is.   You would *not*,
for example, want to maintain a different set of entry guards for
every IP that you receive, since if you did, a hostile DHCP server
could feed you new IPs until you picked a hostile guard. Similarly, if
you are a busy traveller who changes your view of what network you are
on hundreds or thousands of times, your chance of picking a hostile
guard would rise accordingly.

We'd also need to figure out the storage issues here. Having a record
in your state file of every network you have visited is not
necessarily the best idea either.


As an alternative solution, Roger has been advocating for reducing the
default number of client guards to 1, to avoid the property of letting
guard choices identify Tor clients.  I for one am hoping that there
will be some good solution that partitions guards into N sets of m,
such that clients will fall into N classes rather than Nm choose 3...
but it's hard to design such a solution in a way that makes the
partitions secure against an adaptive attacker.  So perhaps Roger's
idea is best here.


best wishes,
-- 
Nick
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev