[tor-bugs] #6537 [Tor Client]: Possible timing side-channel in router selection

[Tor Bug Tracker & Wiki]

#6537: Possible timing side-channel in router selection
---------------------------+------------------------------------------------
    Reporter:  nickm       |       Owner:                    
        Type:  defect      |      Status:  closed            
    Priority:  major       |   Milestone:  Tor: 0.2.2.x-final
   Component:  Tor Client  |     Version:                    
  Resolution:  fixed       |    Keywords:                    
      Parent:              |      Points:                    
Actualpoints:              |  
---------------------------+------------------------------------------------

Comment(by nickm_mobile):

 Yeah, it's not an *easy* attack. I'm not even convinced that the attacker
 can get a nonzero amount of timing bits to even work with anyway, due to
 the noise in the rest of the system.  That said, there are indeed cases
 where the attacker can know something about the ordering.  ISTR that when
 these functions are used to choose a routerstatus, that's in consensus
 order often.  Also, if a client uses some of my nodes as directories to
 download routerinfos, I can force those nodes to appear late in the list,
 possibly in an order of my choosing.  Finally, even if I start knowing
 nothing about a list's order, I could still know that later routerinfos
 are those that a client chose to update more recently.

 I don't have the code in front of me right now, so I probably have some
 details wrong, and I forget completely what we do with microdescs:
 probably pick them in routerstatus order. :/

 Tl;dr: The attack here is hard; I am not 100%convinced it is possible; but
 there are some bits leaked. There are. Enough historical traffic analysis
 attacks that I am not happy trusting that a tiny leak will remain safe.

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