diff options
| -rw-r--r-- | doc/tor-design.tex | 81 |
1 files changed, 16 insertions, 65 deletions
diff --git a/doc/tor-design.tex b/doc/tor-design.tex index 6baac8323..9142edce4 100644 --- a/doc/tor-design.tex +++ b/doc/tor-design.tex @@ -212,7 +212,7 @@ We review previous work in Section~\ref{sec:related-work}, describe 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}. @@ -321,7 +321,8 @@ Systems like Freedom and the original Onion Routing build the circuit 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. @@ -433,7 +434,7 @@ is appealing, but still has many open problems \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 @@ -605,7 +606,7 @@ In Tor, each circuit can be shared by many TCP streams. To avoid 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 @@ -1100,7 +1101,7 @@ adversary can exploit differences in client knowledge: clients who use 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 @@ -1280,69 +1281,19 @@ also designed to include authentication/authorization---if Alice doesn't 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. |