[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[or-cvs] r10603: Change suggestions from our editor (tor/trunk/doc/design-paper)
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 @@
}
+@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",