commit 005d4af2af8e7af5888e7151f0dcd1892a24b014 Author: Nick Mathewson <nickm@torproject.org> Date: Wed Nov 14 00:50:25 2012 -0500 integrate more of the guard nodes section --- tor-design-2012.tex | 48 +++++++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 47 insertions(+), 1 deletions(-) diff --git a/tor-design-2012.tex b/tor-design-2012.tex index ebe39e8..69c04a6 100644 --- a/tor-design-2012.tex +++ b/tor-design-2012.tex @@ -1047,7 +1047,53 @@ section~\ref{what?XXX}). A subset of the authorities measure and vote on nodes' observed bandwidth, to prevent misbehaving nodes from claiming (intentionally or accidentally) to have too much capacity. -\subsubection{Avoiding duplicate node families in the same circuit} +\subsubsection{Guard nodes} + +We assume that if an +attacker controls or monitors the first hop and last hop of a +circuit, then the attacker can de-anonymize the user by correlating +timing and volume information. Many of the security improvements to +path selection discussed in this post concentrate on reducing the +probability that an attacker can be in this position, but no +reasonably efficient proposal can eliminate the possibility. + +Therefore, each time a user creates a circuit, there is a small +chance that the circuit will be compromised. However, most users +create a large number of Tor circuits, so with the original path +selection algorithm, these small chances would build up into a +large chance that at least one of their circuits would be +compromised. For users whose goal is to avoid having any of their +communications partners learned, having a fraction of their circuits +compromised is as unacceptable as having all of them compromised. + +To help improve this situation Tor uses Guard Nodes (initially +called "helper nodes", invented by Wright, Adler, Levine, and +Shields and proposed for use in Tor by Øverlier and Syverson). Each +Tor client picks a few Tor nodes to use persistently as its +"guards", and uses one of them as the first hop for all circuits (as +long as those nodes remain operational). + +This doesn't affect the probability that the first circuit is +compromised, but it does mean that if the guard nodes chosen by a +user are not attacker-controlled all their future circuits will be +safe. On the other hand, users who choose attacker-controlled guards +will have about $c/N$ of their circuits compromised, where $c$ is the +amount of attacker-controlled network resource and $N$ is the total +network resource. Without guard nodes every circuit has a $(c/N)^2$ +probability of being compromised. + +Essentially, the guard node approach recognises that some circuits +are going to be compromised, but it's better to increase your +probability of having no compromised circuits at the expense of also +increasing the proportion of your circuits that will be compromised +if any of them are. This is because compromising a fraction of a +user's circuits—sometimes even just one—can be enough to compromise +a user's anonymity. For users who have good guard nodes, the +situation is much better, and for users with bad guard nodes the +situation is not much worse than before. + + +\subsubsection{Avoiding duplicate node families in the same circuit} As mentioned above, if the first and last node in a circuit are controlled by an adversary, they can use traffic correlation attacks