[tor-bugs] #9767 [Tor]: Implement proposal 222: Eliminate client timestamps in Tor

[Tor Bug Tracker & Wiki]

#9767: Implement proposal 222: Eliminate client timestamps in Tor
-------------------------+-------------------------------------------------
     Reporter:  nickm    |      Owner:
         Type:  defect   |     Status:  needs_review
     Priority:  major    |  Milestone:  Tor: 0.2.4.x-final
    Component:  Tor      |    Version:
   Resolution:           |   Keywords:  tor-client fingerprinting time
Actual Points:           |  prop222
       Points:           |  Parent ID:
-------------------------+-------------------------------------------------

Comment (by andrea):

 Replying to [comment:9 nickm]:
 > Replying to [comment:5 andrea]:
 > > As for the changes to Tor in no_client_timestamps_024:
 > >
 > >  * c78e5b07a6a32f2de46f9c628e37e2fbc3aa90ca: this looks okay to me;
 I'm assuming I remember the protocol correctly and it's always possible
 for anyone receiving a NETINFO to know anyway whether it came from a
 client or relay, so this doesn't leak any new information.
 > >  * ae0fe705dbcfba056988667c04c355f8aaa1669d: the changes file mentions
 INTRODUCE2 cells, but the change affects code that generates INTRODUCE1
 cells at the client end.
 >
 > Hm.  Perhaps I should just say "INTRODUCE"?  The INTRODUCE(n) cell has
 an INTRODUCE(3-n) cell inside it, but remembering whether n=2 or n=1 in
 that sentence is beyond me.
 >
 > >  * 5c22af4bef9d3ce820c50b09f0ebde91b90246f9: this looks okay to me
 > >  * 64a139f8db9515b99513d50d3a1b9f524a6f8ad3: this looks okay to me;
 can we get rid of the timestamps in the descriptors when we have a new HS
 protocol, perhaps?
 >
 > I hope so.  Rather, let's pitch a fit if anybody proposes one.
 >
 > It sounds like the Tor part of this is mergeable?  Into 0.2.4?  :)

 Yeah, agree on mergeability there.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9767#comment:12>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online