Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Create a new issue
  • Issue Boards

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #10969

Closed (moved)
Open
Opened Feb 20, 2014 by George Kadianakis@asn

Set of guard nodes can act as a linkability fingerprint

It's well understood that your set of guard nodes can act as a fingerprint. Some calculations can be found in comment:3:ticket:9273 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.

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).

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 https://github.com/leewoboo/tordyguards) but how does little-t-tor knows when we changed network? There is some more discussion on this topic here: https://lists.torproject.org/pipermail/tor-dev/2013-September/005424.html

To upload designs, you'll need to enable LFS and have admin enable hashed storage. More information
Assignee
Assign to
Tor: unspecified
Milestone
Tor: unspecified
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#10969