Tor Bug Tracker & Wiki: Ticket Query!closed&keywords=~prop259&desc=1&order=id The Tor Project: anonymity online en-US Tor Bug Tracker & Wiki /images/tor-logo.png!closed&keywords=~prop259&desc=1&order=id Trac 1.2 #17295: Route-selection and guard-selection logic completely replaced Wed, 07 Oct 2015 16:05:31 GMT nickm <p> By Nov 2016, we have a deliverable to get our route selection much more right than today, and to have it very tested. We should get this done significantly earlier. </p> Results #10969: Set of guard nodes can act as a linkability fingerprint Thu, 20 Feb 2014 13:57:03 GMT asn <p> It's well understood that your set of guard nodes can act as a fingerprint. Some calculations can be found in <a class="closed ticket" href="" title="Comment 3 for #9273: project: Brainstorm tradeoffs from moving to 2 (or even 1) guards (closed: implemented)">comment:3:ticket:9273</a> but it's pretty clear that each 3-subset of guards is rare enough that it's very likely that no other clients have exactly the same. </p> <p> There are a few proposed ideas on how to reduce the linkability of guard nodes sets. For example, reducing the number of guard nodes to 1 will help against this. Still, as an example, in a city with only 500 Tor users, even if each person has a single guard, there are only going to be a few people with the same guard node (and some of them might always be in the same physical location, so the one who roams is probably the same person). </p> <p> To further improve on the above, maybe it makes sense to pick N guards but only use 1 of them at a time -- and cycle through the N guards every now and then. Maybe we should cycle everytime we change network (see <a class="ext-link" href=""><span class="icon">​</span></a>) but how does little-t-tor knows when we changed network? There is some more discussion on this topic here: <a class="ext-link" href=""><span class="icon">​</span></a> </p> Results