diff options
| -rw-r--r-- | doc/tor-design.tex | 43 |
1 files changed, 20 insertions, 23 deletions
diff --git a/doc/tor-design.tex b/doc/tor-design.tex index b9e7a56a4..82e84059f 100644 --- a/doc/tor-design.tex +++ b/doc/tor-design.tex @@ -119,25 +119,25 @@ application-level proxies such as Privoxy \cite{privoxy}, without trying to duplicate those features itself. \textbf{No mixing, padding, or traffic shaping yet:} Onion -Routing originally called for batching and reordering cells arriving from -each source, and assumed padding between ORs and, in a -later design, between onion proxies (users) and onion routers +Routing originally called for batching and reordering cells as they arrived, +assumed padding between ORs, and in +later designs added padding between onion proxies (users) and ORs \cite{or-ih96,or-jsac98}. Tradeoffs between padding protection and cost were discussed, but no general padding scheme was suggested. -It was theorized, \cite{or-pet00}, but not described how \emph{traffic - shaping} would generally be used. Recent research \cite{econymics} +It was theorized \cite{or-pet00} but not described how \emph{traffic + shaping} would be used. Recent research \cite{econymics} and deployment experience \cite{freedom21-security} suggest that this level of resource use is not practical or economical; and even full link padding is still vulnerable \cite{defensive-dropping}. Thus, until we have a proven and convenient design for traffic shaping or -low-latency mixing that will improve anonymity against a realistic +low-latency mixing that improves anonymity against a realistic adversary, we leave these strategies out. \textbf{Many TCP streams can share one circuit:} Onion Routing originally built a separate circuit for each -application-level request, requiring -multiple public key operations for every request, and also presenting -a threat to anonymity from building so many different circuits; see +application-level request, but this required +multiple public key operations for every request, and also presented +a threat to anonymity from building so many circuits; see Section~\ref{sec:maintaining-anonymity}. Tor multiplexes multiple TCP streams along each circuit to improve efficiency and anonymity. @@ -157,7 +157,7 @@ congestion control uses end-to-end acks to maintain anonymity while allowing nodes at the edges of the network to detect congestion or flooding and send less data until the congestion subsides. -\textbf{Directory servers:} Earlier Onion Routing design +\textbf{Directory servers:} Earlier Onion Routing designs planned to flood link-state information through the network---an approach that can be unreliable and open to partitioning attacks or deception. Tor takes a simplified view toward distributing link-state @@ -174,9 +174,9 @@ is comfortable with allowing different types of traffic to exit the Tor network from his node. \textbf{End-to-end integrity checking:} The original Onion Routing -design did no integrity checking on data. Any OR on the +design did no integrity checking on data. Any node on the circuit could change the contents of data cells as they passed by---for -example, to alter a connection request on the fly so it would connect +example, to alter a connection request so it would connect to a different webserver, or to `tag' encrypted traffic and look for corresponding corrupted traffic at the network edges \cite{minion-design}. Tor hampers these attacks by checking data integrity before it leaves @@ -200,8 +200,8 @@ to connect with hidden servers; reply onions are no longer required. Unlike Freedom \cite{freedom2-arch}, Tor only tries to anonymize -TCP streams. It does not require patches (or built-in support) in an -operating system's network stack, which has been valuable to Tor's +TCP streams. Not requiring patches (or built-in support) in an +operating system's network stack has been valuable to Tor's portability and deployability. We have implemented most of the above features. Our source code is @@ -429,8 +429,7 @@ deployability, readability, and ease of security analysis. Tor aims to deploy a simple and stable system that integrates the best well-understood approaches to protecting anonymity.\\ -\noindent{\large\bf Non-goals}\\ -\label{subsec:non-goals} +\noindent{\large\bf Non-goals}\label{subsec:non-goals}\\ In favoring simple, deployable designs, we have explicitly deferred several possible goals, either because they are solved elsewhere, or because they are not yet solved. @@ -472,8 +471,8 @@ A global passive adversary is the most commonly assumed threat when analyzing theoretical anonymity designs. But like all practical low-latency systems, Tor does not protect against such a strong adversary. Instead, we assume an adversary who can observe some fraction -of network traffic; who can generate, modify, delete, or delay traffic -on the network; who can operate onion routers of its own; and who can +of network traffic; who can generate, modify, delete, or delay +traffic; who can operate onion routers of its own; and who can compromise some fraction of the onion routers. In low-latency anonymity systems that use layered encryption, the @@ -623,10 +622,8 @@ to each other through a given exit node. Also, because circuits are built in the background, OPs can recover from failed circuit creation without delaying streams and thereby harming user experience.\\ -\noindent{\large\bf Constructing a circuit}\\ +\noindent{\large\bf Constructing a circuit}\label{subsubsec:constructing-a-circuit}\\ %\subsubsection{Constructing a circuit} -\label{subsubsec:constructing-a-circuit} -% A user's OP constructs circuits incrementally, negotiating a symmetric key with each OR on the circuit, one hop at a time. To begin creating a new circuit, the OP (call her Alice) sends a @@ -1220,8 +1217,8 @@ identity even in the presence of router failure. Bob's service must not be tied to a single OR, and Bob must be able to tie his service to new ORs. \textbf{Smear-resistant:} A social attacker who offers an illegal or disreputable location-hidden -service should not be able to ``frame'' a rendezvous router---that is, -make observers believe that the router created that service. +service should not be able to ``frame'' a rendezvous router by +making observers believe the router created that service. %slander-resistant? defamation-resistant? \textbf{Application-transparent:} Although we require users to run special software to access location-hidden servers, we must not |