Skip to content
Snippets Groups Projects
Commit d48cebc5 authored by Nick Mathewson's avatar Nick Mathewson :game_die:
Browse files

Try to clarify impact of bug 6537

I don't personally agree that this is likely to be easy to exploit,
and some initial experimention I've done suggests that cache-miss
times are just plain too fast to get useful info out of when they're
mixed up with the rest of Tor's timing noise.  Nevertheless, I'm
leaving Robert's initial changelog entry in the git history so that he
can be the voice of reason if I'm wrong. :)
parent 308f6dad
No related branches found
No related tags found
No related merge requests found
......@@ -3,10 +3,12 @@
- Try to leak less information about what relays a client is
choosing to a side-channel attacker. Previously, a Tor client
would stop iterating through the list of available relays as
soon as it had chosen one, thus leaking information about which
relays it picked for a circuit to a timing attack. (Tor is
likely to still leak information about which relays it has
chosen for a circuit to other processes on the same computer,
through e.g. which cache lines it loads while building the
circuit.)
soon as it had chosen one, thus finishing a little earlier
when it picked a router earlier in the list. If an attacker
can recover this timing information (nontrivial but not
proven to be impossible), they could learn some coarse-
grained information about which relays a client was picking
(middle nodes in particular are likelier to be affected than
exits). The timing attack might be mitigated by other factors
(see bug #6537 for some discussion), but it's best not to
take chances. Fixes bug 6537; bugfix on 0.0.8rc1.
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment