[or-cvs] r10603: Change suggestions from our editor (tor/trunk/doc/design-paper)

[syverson at seul.org]

Author: syverson
Date: 2007-06-14 17:05:28 -0400 (Thu, 14 Jun 2007)
New Revision: 10603

Modified:
   tor/trunk/doc/design-paper/sptor.tex
   tor/trunk/doc/design-paper/tor-design.bib
Log:
Change suggestions from our editor


Modified: tor/trunk/doc/design-paper/sptor.tex
===================================================================
--- tor/trunk/doc/design-paper/sptor.tex	2007-06-14 14:29:25 UTC (rev 10602)
+++ tor/trunk/doc/design-paper/sptor.tex	2007-06-14 21:05:28 UTC (rev 10603)
@@ -76,9 +76,15 @@
 list of Tor nodes from several central \emph{directory servers} via a
 voting protocol to avoid dependence on or complete trust in any one of
 them, and incrementally creates a private pathway or \emph{circuit} of
-encrypted connections through authenticated Tor nodes on the network,
+encrypted connections through authenticated Tor nodes on the network
+whose public keys were obtained form the directory servers,
 negotiating a separate set of encryption keys for each hop along the
-circuit.  The circuit is extended one node at a time, and each node
+circuit. The nodes in the circuit are chosen at random by the client
+subject to a preference for higher performing nodes to allocate
+resources effectively and with a client-chosen preferred set of first
+nodes called \emph{entry guards} to complicate profiling attacks by
+internal adversaries~\cite{hs-attack}.
+The circuit is extended one node at a time, and each node
 along the way knows only the immediately previous and following nodes
 in the circuit, so no individual Tor node knows the complete path that
 each fixed-sized data packet (or \emph{cell}) will take.  Thus,
@@ -148,8 +154,14 @@
 neither limit ordinary users to content and services available only
 within our network nor require them to take on responsibility for
 connections outside the network, unless they separately choose to run
-server nodes.
+server nodes. Nonetheless because we support low-latency interactive
+communications, end-to-end \emph{traffic correlation}
+attacks~\cite{danezis:pet2004,defensive-dropping,SS03,hs-attack,bauer:tr2007}
+allow an attacker who can observe both ends of a communication to
+correlate packet timing and volume, quickly linking the initiator to
+her destination.
 
+
 Our defense lies in having a diverse enough set of nodes to prevent
 most real-world adversaries from being in the right places to attack
 users, by distributing each transaction over several nodes in the

Modified: tor/trunk/doc/design-paper/tor-design.bib
===================================================================
--- tor/trunk/doc/design-paper/tor-design.bib	2007-06-14 14:29:25 UTC (rev 10602)
+++ tor/trunk/doc/design-paper/tor-design.bib	2007-06-14 21:05:28 UTC (rev 10603)
@@ -9,6 +9,14 @@
 }
 
 
+ at TechReport{bauer:tr2007,
+  author = 	 {Kevin Bauer and Damon McCoy and Dirk Grunwald and Tadayoshi Kohno and Douglas Sicker},
+  title = 	 {Low-Resource Routing Attacks Against Anonymous Systems},
+  institution =  {University of Colorado at Boulder},
+  year = 	 2007,
+  number = 	 {CU-CS-1025-07}
+}
+
 % fix me
 @misc{tannenbaum96,
   author = "Andrew Tannenbaum",