On Wed, Sep 11, 2013 at 11:20:59AM -0400, Nick Mathewson wrote: > 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.) Is this tradeoff of using entry guards documented somewhere? I suspect that there may be many users changing their MAC address to protect themselves against this exact threat while not understanding that their entry guard set uniquely identifies them. Perhaps the man page text about UseEntryGuards and NumEntryGuards should mention it? A FAQ entry would be nice too. ~leif > > 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
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev