[or-cvs] Commit rest of changes to section 3. I am falling asleep, ...

Nick Mathewson nickm at seul.org
Thu Oct 30 05:24:41 UTC 2003

Update of /home/or/cvsroot/doc
In directory moria.mit.edu:/tmp/cvs-serv12412

Modified Files:
Log Message:
Commit rest of changes to section 3.  I am falling asleep, and my section 4 edits are not yet grammatical

Index: tor-design.tex
RCS file: /home/or/cvsroot/doc/tor-design.tex,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -d -r1.37 -r1.38
--- tor-design.tex	30 Oct 2003 04:05:28 -0000	1.37
+++ tor-design.tex	30 Oct 2003 05:24:38 -0000	1.38
@@ -268,9 +268,9 @@
 Modern anonymity designs date to Chaum's Mix-Net\cite{chaum-mix} design of
 1981.  Chaum proposed hiding sender-recipient connections by wrapping
 messages in several layers of public key cryptography, and relaying them
-through a path composed of Mix servers.  Mix servers in turn decrypt, delay,
-and re-order messages, before relay them along the path towards their
+through a path composed of ``Mixes.''  These mixes in turn decrypt, delay,
+and re-order messages, before relaying them along the sender-selected
+path towards their destinations.
 Subsequent relay-based anonymity designs have diverged in two
 principal directions.  Some have attempted to maximize anonymity at
@@ -643,33 +643,35 @@
 no resistance to traffic confirmation; it does.  We defer discussion
 of this point and of particular attacks until Section~\ref{sec:attacks},
 after we have described Tor in more detail.)
+% XXX We need to say what traffic analysis is:  How about...
+On the other hand, we {\it do} try to prevent an attacker from
+performing traffic analysis: that is, attempting to learn the communication
+partners of an arbitrary user.
+% XXX If that's not right, what is?  It would be silly to have a
+% threat model section without saying what we want to prevent the
+% attacker from doing. -NM
+% XXX Also, do we want to mention linkability or building profiles? -NM
-\SubSection{Known attacks against low-latency anonymity systems}
-% Should be merged into ``Threat model'' and reiterated in Attacks. -NM
-We discuss each of these attacks in more detail below, along with the
-aspects of the Tor design that provide defense. We provide a summary
-of the attacks and our defenses against them in Section~\ref{sec:attacks}.
-Passive attacks:
-simple observation,
-timing correlation,
-size correlation,
-option distinguishability,
+Our assumptions about our adversary's capabilities imply a number of
+possible attacks against users' anonymity.  Our adversary might try to
+mount passive attacks by observing the edges of the network and
+correlating traffic entering and leaving the network: either because
+of relationships in packet timing; relationships in the volume of data
+sent; [XXX simple observation??]; or relationships in any externally
+visible user-selected options.  The adversary can also mount active
+attacks by trying to compromise all the servers' keys in a
+path---either through illegitimate means or through legal coercion in
+unfriendly jurisdiction; by selectively DoSing trustworthy servers; by
+introducing patterns into entering traffic that can later be detected;
+or by modifying data entering the network and hoping that trashed data
+comes out the other end.  The attacker can additionally try to
+decrease the network's reliability by performing antisocial activities
+from reliable servers and trying to get them taken down.
+% XXX Should there be more or less?  Should we turn this into a
+% bulleted list?  Should we cut it entirely?
-Active attacks:
-key compromise,
-iterated subpoena,
-run recipient,
-run a hostile node,
-compromise entire path,
-selectively DOS servers,
-introduce timing into messages,
-directory attacks,
-tagging attacks,
-smear attacks,
-entrapment attacks
+We list these attacks and more, and describe our defenses against them
+in Section~\ref{sec:attacks}.

More information about the tor-commits mailing list