[or-cvs] Trim 10 lines. Roger, please revert any of this you disagr...

Nick Mathewson nickm at seul.org
Sun Feb 1 04:09:18 UTC 2004


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

Modified Files:
	tor-design.tex 
Log Message:
Trim 10 lines.  Roger, please revert any of this you disagree with.

Index: tor-design.tex
===================================================================
RCS file: /home/or/cvsroot/doc/tor-design.tex,v
retrieving revision 1.146
retrieving revision 1.147
diff -u -d -r1.146 -r1.147
--- tor-design.tex	1 Feb 2004 03:09:32 -0000	1.146
+++ tor-design.tex	1 Feb 2004 04:09:15 -0000	1.147
@@ -316,10 +316,10 @@
 cascade~\cite{web-mix}. However, it is not demonstrated whether the current
 implementation's padding policy improves anonymity.
 
-{\bf PipeNet}~\cite{back01, pipenet}, another low-latency design proposed at
-about the same time as Onion Routing, provided
-stronger anonymity at the cost of allowing a single user to shut
-down the network simply by not sending. Systems like {\bf ISDN
+{\bf PipeNet}~\cite{back01, pipenet}, another low-latency design proposed
+around the same time as Onion Routing, gave
+stronger anonymity but allowed a single user to shut
+down the network by not sending. Systems like {\bf ISDN
 mixes}~\cite{isdn-mixes} were designed for other environments with
 different assumptions.
 %XXX please can we fix this sentence to something less demeaning
@@ -340,15 +340,15 @@
 although Herbivore users can make external connections by
 requesting a peer to serve as a proxy.
 
-Systems like {\bf Freedom} and the original Onion Routing build the circuit
+Systems like {\bf Freedom} and the original Onion Routing build circuits
 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
+each layer of which provides session keys and the address of the
 next server in the circuit. Tor as described herein, Tarzan, MorphMix,
 {\bf Cebolla}~\cite{cebolla}, and Rennhard's {\bf Anonymity Network}~\cite{anonnet}
-build the circuit
-in stages, extending it one hop at a time.
+build circuits
+in stages, extending them one hop at a time.
 Section~\ref{subsubsec:constructing-a-circuit} describes how this
-approach makes perfect forward secrecy feasible.
+approach enables perfect forward secrecy.
 
 Circuit-based anonymity designs must choose which protocol layer
 to anonymize. They may choose to intercept IP packets directly, and
@@ -1311,11 +1311,13 @@
 of Onion Routing, Tor can directly use Privoxy and related
 filtering services to anonymize application data streams.
 
-\emph{Option distinguishability.} We allow clients to choose local
+\emph{Option distinguishability.} We allow clients to choose
 configuration options. For example, clients concerned about request
 linkability should rotate circuits more often than those concerned
-about traceability. There is economic incentive to attract users by
-allowing this choice; but at the same time, a set of clients who are
+about traceability. Allowing choice may attract users with different 
+%There is economic incentive to attract users by
+%allowing this choice; 
+needs; but clients who are
 in the minority may lose more anonymity by appearing distinct than they
 gain by optimizing their behavior~\cite{econymics}.
 
@@ -1558,7 +1560,7 @@
 to two factors. First, network latency is critical: we are
 intentionally bouncing traffic around the world several times. Second,
 our end-to-end congestion control algorithm focuses on protecting
-volunteer servers from accidental DoS rather than optimizing
+volunteer servers from accidental DoS rather than on optimizing
 performance. % Right now the first $500 \times 500\mbox{B}=250\mbox{KB}$
 %of the stream arrives
 %quickly, and after that throughput depends on the rate that \emph{relay
@@ -1819,8 +1821,10 @@
 
 In this appendix we provide more specifics about the rendezvous points
 of Section~\ref{subsec:rendezvous}. We also describe integration
-issues, related work, and how well the rendezvous point design
-withstands various attacks.
+issues and related work.
+%, and how well the rendezvous point design
+%withstands various attacks.
+%    (Not any more; it's currently commented out. -NM)
 
 \SubSection{Rendezvous protocol overview}
 
@@ -1841,9 +1845,9 @@
       rendezvous cookie to recognize Bob.
 \item Alice opens an anonymous stream to one of Bob's introduction
       points, and gives it a message (encrypted to Bob's public key)
-      that tells him
-      about herself, her chosen RP and the rendezvous cookie, and the
-      first half of a DH
+      telling it about herself,
+      her RP and rendezvous cookie, and the
+      start of a DH
       handshake. The introduction point sends the message to Bob.
 \item If Bob wants to talk to Alice, he builds a circuit to Alice's
       RP and sends the rendezvous cookie, the second half of the DH
@@ -1853,8 +1857,8 @@
       shares the key only with Bob.
 \item The RP connects Alice's circuit to Bob's. Note that RP can't
       recognize Alice, Bob, or the data they transmit.
-\item Alice now sends a \emph{relay begin} cell along the circuit. It
-      arrives at Bob's onion proxy. Bob's onion proxy connects to Bob's
+\item Alice sends a \emph{relay begin} cell along the circuit. It
+      arrives at Bob's OP, which connects to Bob's
       webserver.
 \item An anonymous stream has been established, and Alice and Bob
       communicate as normal.
@@ -1890,11 +1894,11 @@
 he can provide selected users
 with a current list and/or future schedule of introduction points that
 are not advertised in the DHT\@. This is most likely to be practical
-if there is a relatively stable and large group of introduction points
+if there is a stable and large group of introduction points
 available. Alternatively, Bob could give secret public keys
 to selected users for consulting the DHT\@. All of these approaches
 have the advantage of limiting exposure even when
-some of the selected high-priority users collude in the DoS\@.
+some of the selected users collude in the DoS\@.
 
 \SubSection{Integration with user applications}
 



More information about the tor-commits mailing list