More edits to edits; a few formatting fixes

svn:r760

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