[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #6537 [Tor Client]: Possible timing side-channel in router selection
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs