# [or-cvs] tweak tweak

Roger Dingledine arma at seul.org
Thu Oct 30 12:10:27 UTC 2003

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

Modified Files:
tor-design.tex
Log Message:
tweak tweak

Index: tor-design.tex
===================================================================
RCS file: /home/or/cvsroot/doc/tor-design.tex,v
retrieving revision 1.39
retrieving revision 1.40
diff -u -d -r1.39 -r1.40
--- tor-design.tex	30 Oct 2003 11:40:14 -0000	1.39
+++ tor-design.tex	30 Oct 2003 12:10:24 -0000	1.40
@@ -434,7 +434,7 @@
for every protocol).  This requirement also precludes systems in which
users who do not benefit from anonymity are required to run special
software in order to communicate with anonymous parties.
-% XXX Our rendezvous points require clients to use our software to get to
+%     Our rendezvous points require clients to use our software to get to
%     the location-hidden servers.
%     Or at least, they require somebody near the client-side running our
%     software. We haven't worked out the details of keeping it transparent
@@ -517,10 +517,10 @@
communicating with.
\end{description}

+\SubSection{Threat Model}
+\label{subsec:threat-model}

-A global passive adversary is the most commonly assumed when
+A global passive adversary is the most commonly assumed threat when
analyzing theoretical anonymity designs. But like all practical low-latency
systems, Tor is not secure against this adversary.  Instead, we assume an
adversary that is weaker than global with respect to distribution, but that
@@ -682,7 +682,7 @@
% XXX Should there be more or less?  Should we turn this into a
% bulleted list?  Should we cut it entirely?

-We list these attacks and more, and describe our defenses against them
+We consider these attacks and more, and describe our defenses against them
in Section~\ref{sec:attacks}.

@@ -771,7 +771,8 @@
and expire old used circuits that are no longer in use. Thus even very
active users spend a negligible amount of time and CPU in building
circuits, but only a limited number of requests can be linked to each
-other by a given exit node.
+other by a given exit node. Also, because circuits are built in the
+background, an already failed router never affects the user experience.

Users set up circuits incrementally, negotiating a symmetric key with
each hop one at a time. To create a new circuit, the user (call her
@@ -814,9 +815,7 @@

Once Alice has established the circuit (so she shares a key with each
OR on the circuit), she can send relay cells.
-%The stream ID in the relay header indicates to which stream the cell belongs.
-% Nick: should i include the above line?
-% Paul says yes. -PS
+The stream ID in the relay header indicates to which stream the cell belongs.
Alice can address each relay cell to any of the ORs on the circuit. To
construct a relay cell destined for a given OR, she iteratively
@@ -924,29 +923,18 @@
The attacker must be able to guess all previous bytes between Alice
and Bob on that circuit (including the pseudorandomness from the key
negotiation), plus the bytes in the current cell, to remove or modify the
-cell. The computational overhead isn't so bad, compared to doing an AES
-% XXX We never say we use AES. Say it somewhere above?
+cell. Attacks on SHA-1 where the adversary can incrementally add to a
+hash to produce a new valid hash \cite{practical-crypto} don't work,
+% XXX Do we want to cite practical crypto here, or is there a better
+%     place to cite, or is this well-known enough to leave out a cite? -RD
+because all hashes are end-to-end encrypted across the circuit.
+% XXX We never say we use AES. Say it somewhere above? -RD
crypt at each hop in the circuit. We use only four bytes per cell to
valid hash, plus the payload the current cell, is acceptly low, given
that Alice or Bob tear down the circuit if they receive a bad hash.

-%% probably don't need to even mention this, because the randomness
-%% covers it:
-%The fun SHA1 attack where the bad guy can incrementally add to a hash
-%to get a new valid hash doesn't apply to us, because we never show any
-%hashes to anybody.
-
-\SubSection{Website fingerprinting attacks}
-
-% this subsection probably wants to move to analysis -RD
-old onion routing is vulnerable to website fingerprinting attacks like
-david martin's from usenix sec and drew's from pet2002. so is tor. we
-(to foil the first hop), to solve this. let's hope somebody writes
-a followup to \cite{defensive-dropping} that tells us what, exactly,
-to do, and why, exactly, it helps.
-
\SubSection{Rate limiting and fairness}

Nodes use a token bucket approach \cite{foo} to limit the number of
@@ -1534,8 +1522,17 @@
\item \textbf{Passive attacks}
\begin{itemize}
\item \emph{Observing user behavior.}
-\item \emph{Timing correlation.}
-\item \emph{Size correlation.}
+\item \emph{End-to-end Timing correlation.}
+\item \emph{End-to-end Size correlation.}
+\item \emph{Website fingerprinting attacks} old onion routing is
+vulnerable to website fingerprinting attacks like david martin's
+from usenix sec and drew's from pet2002. so is tor. we need to send