[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #10969 [Core Tor/Tor]: Set of guard nodes can act as a linkability fingerprint



#10969: Set of guard nodes can act as a linkability fingerprint
-------------------------------------------------+-------------------------
 Reporter:  asn                                  |          Owner:
                                                 |  mikeperry
     Type:  defect                               |         Status:  closed
 Priority:  High                                 |      Milestone:  Tor:
                                                 |  unspecified
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:  fixed
 Keywords:  tor-client, tor-guard, XKEYSCORE,    |  Actual Points:
  prop259, SponsorU-deferred, QUICKANT           |
Parent ID:                                       |         Points:  large
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by isis):

 Replying to [comment:41 cypherpunks]:
 > Replying to [comment:40 cypherpunks]:
 > > Hi isis, I'm again reopening this ticket because the fundamental
 problem in the title and description ("set of guard nodes can act as a
 linkability fingerprint") remains unfixed.

 This is actually fair. The new guard algorithm, as you're probably aware,
 has a concept of `SAMPLED_GUARDS` which is a subset of all the available
 guards in the consensus, and tor (>=0.3.x) will only connect to those. At
 any given point, a client will only have one guard. However, there's
 probably some super weird edge-cases, like "if your guard has stopped
 answering EXTEND cells but it's still behaving properly for circuits
 you've already created" then maybe tor could be tricked into keeping the
 circuits that still work while using a new, different guard for the other
 circuits. (Although, this more-fingerprintable state—if it's
 possible—wouldn't exist for long.)

 Anyway, I guess what I mean to say is that this specific issue with guard
 linkability shouldn't be an issue anymore, but there's definitely still
 improvements which could be made to the guard algorithm.

 > > I just checked a friend's laptop (Debian stable, tor
 0.2.9.11-1~deb9u1) and when it got online it immediately connected to four
 guards. I don't know why, but I suspect it's because (like most laptops)
 it is sometimes not connected to the internet. (Some time later, it
 remained connected to two of them.)
 >
 > Sorry but that doesn't disprove what Isis said, Prop271 was implemented
 in Tor 0.3.0.x and not 0.2.9.x which your laptop's friend had.

 nickm and asn and I talked about this ticket a bit in IRC, and I think the
 general consensus was to make a new tracking ticket for guard algorithm
 issues/improvements, with specific child tickets that only discuss post-
 prop271 tor behaviours, since this ticket was originally about a part of
 the code that has been nearly entirely replaced.

 I have a slight preference for a new ticket, but I'll happily defer to
 whatever other people think is the logical thing to do.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/10969#comment:42>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs