[tor-commits] [tor-design-2012/master] integrate more of the guard nodes section

[nickm@xxxxxxxxxxxxxx]

commit 005d4af2af8e7af5888e7151f0dcd1892a24b014
Author: Nick Mathewson <nickm@xxxxxxxxxxxxxx>
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

_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits