our goals and assumptions in Section~\ref{sec:assumptions},
and then address the above list of improvements in
Sections~\ref{sec:design}-\ref{sec:rendezvous}. We summarize
-in Section~\ref{sec:analysis} how our design stands up to
+in Section~\ref{sec:attacks} how our design stands up to
known attacks, and conclude with a list of open problems in
Section~\ref{sec:maintaining-anonymity} and future work for the Onion
Routing project in Section~\ref{sec:conclusion}.
all at once, using a layered ``onion'' of public-key encrypted messages,
each layer of which provides a set of session keys and the address of the
next server in the circuit. Tor as described herein, Tarzan, MorphMix,
-Cebolla \cite{cebolla}, and AnonNet \cite{anonnet} build the circuit
+Cebolla \cite{cebolla}, and Rennhard's Anonymity Network \cite{anonnet}
+build the circuit
in stages, extending it one hop at a time.
Section~\ref{subsubsec:constructing-a-circuit} describes how this
approach makes perfect forward secrecy feasible.
\textbf{Not secure against end-to-end attacks:} Tor does not claim
to provide a definitive solution to end-to-end timing or intersection
attacks. Some approaches, such as running an onion router, may help;
-see Section~\ref{sec:analysis} for more discussion.
+see Section~\ref{sec:attacks} for more discussion.
\textbf{No protocol normalization:} Tor does not provide \emph{protocol
normalization} like Privoxy or the Anonymizer. For complex and variable
delays, users construct circuits preemptively. To limit linkability
among their streams, users' OPs build a new circuit
periodically if the previous one has been used,
-and expire old used circuits that no longer have any open streams.
+and expire old used circuits that no longer have any open streams.
OPs consider making a new circuit once a minute: thus
even heavy users spend a negligible amount of time and CPU in
building circuits, but only a limited number of requests can be linked
a node listed on one directory server but not the others are vulnerable.
Thus these directory servers must be synchronized and redundant.
-Valid directories are those signed by a threshold of the directory
+Directories are valid if they are signed by a threshold of the directory
servers.
The directory servers in Tor are modeled after those in Mixminion
include the right cookie with her request for service, Bob need not even
acknowledge his existence.
-\Section{Analysis}
-\label{sec:analysis}
+\Section{Attacks and Defenses}
+\label{sec:attacks}
-In this section, we discuss how well Tor meets our stated design goals
-and its resistance to attacks.
+% XXX In sec4 we should talk about bandwidth classes, which will
+% enable us to accept a lot more ORs than if we continue to
+% require 10mbit connections for all ORs. -RD
-\SubSection{Meeting Basic Goals}
-% None of these seem to say very much. Should this subsection be removed?
-\begin{tightlist}
-\item [Basic Anonymity:] Because traffic is encrypted, changing in
- appearance, and can flow from anywhere to anywhere within the
- network, a simple observer that cannot see both the initiator
- activity and the corresponding activity where the responder talks to
- the network will not be able to link the initiator and responder.
- Nor is it possible to directly correlate any two communication
- sessions as coming from a single source without additional
- information. Resistance to more sophisticated anonymity threats is
- discussed below.
-\item[Deployability:] Tor requires no specialized hardware. Tor
- requires no kernel modifications; it runs in user space (currently
- on Linux, various BSDs, and Windows). All of these imply a low
- technical barrier to running a Tor node. There is an assumption that
- Tor nodes have good relatively persistent net connectivity
- (currently T1 or better);
-% Is that reasonable to say? We haven't really discussed it -P.S.
-% Roger thinks otherwise; he will fix this. -NM
- however, there is no padding overhead, and operators can limit
- bandwidth on any link. Tor is freely available under the modified
- BSD license, and operators are able to choose their own exit
- policies, thus reducing legal and social barriers to
- running a node.
-
-\item[Usability:] As noted, Tor runs in user space. So does the onion
- proxy, which is comparatively easy to install and run. SOCKS-aware
- applications require nothing more than to be pointed at the onion
- proxy; other applications can be redirected to use SOCKS for their
- outgoing TCP connections by drop-in libraries such as tsocks.
-
-\item[Flexibility:] Tor's design and implementation is fairly modular,
- so that, for example, a scalable P2P replacement for the directory
- servers would not substantially impact other aspects of the system.
- Tor runs on top of TCP, so design options that could not easily do
- so would be difficult to test on the current network. However, most
- low-latency protocols are designed to run over TCP. We are currently
- working with the designers of MorphMix to render our two systems
- interoperable. So for, this seems to be relatively straightforward.
- Interoperability will allow testing and direct comparison of the two
- rather different designs.
+% XXX In sec9, we should note that we are currently
+% working with the designers of MorphMix to render our two systems
+% interoperable. So far, this seems to be relatively straightforward.
+% Interoperability will allow testing and direct comparison of the two
+% rather different designs.
-\item[Simple design:] Tor opts for practicality when there is no
- clear resolution of anonymity trade-offs or practical means to
- achieve resolution. Thus, we do not currently pad or mix; although
- it would be easy to add either of these. Indeed, our system allows
- long-range and variable padding if this should ever be shown to have
- a clear advantage. Similarly, we do not currently attempt to
- resolve such issues as Sybil attacks to dominate the network except
- by such direct means as personal familiarity of director operators
- with all node operators.
-\end{tightlist}
-
-\SubSection{Attacks and Defenses}
-\label{sec:attacks}
-
Below we summarize a variety of attacks, and discuss how well our
design withstands them.
projects / thirdparty / tor.git / commitdiff
