[or-cvs] minor edits on edits on edits

[Roger Dingledine]

Update of /home/or/cvsroot/doc
In directory moria.mit.edu:/home2/arma/work/onion/cvs/doc

Modified Files:
	tor-design.bib tor-design.tex 
Log Message:
minor edits on edits on edits


Index: tor-design.bib
===================================================================
RCS file: /home/or/cvsroot/doc/tor-design.bib,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -d -r1.23 -r1.24
--- tor-design.bib	3 Nov 2003 21:44:02 -0000	1.23
+++ tor-design.bib	4 Nov 2003 02:24:30 -0000	1.24
@@ -341,7 +341,6 @@
   author = 	 {Hannes Federrath and Anja Jerichow and Andreas Pfitzmann},
   title = 	 {{MIXes} in Mobile Communication Systems: Location
                   Management with Privacy}, 
-  title =        {Hiding Routing Information},
   booktitle =    {Information Hiding, First International Workshop},
   pages =        {121--135},
   year =         1996,

Index: tor-design.tex
===================================================================
RCS file: /home/or/cvsroot/doc/tor-design.tex,v
retrieving revision 1.85
retrieving revision 1.86
diff -u -d -r1.85 -r1.86
--- tor-design.tex	4 Nov 2003 02:22:24 -0000	1.85
+++ tor-design.tex	4 Nov 2003 02:24:30 -0000	1.86
@@ -1316,7 +1316,7 @@
 the Tor rendezvous system.
 
 Since Bob's introduction points might themselves be subject to DoS he
-could be faced with a choice between keeping large numbers of
+could be faced with a choice between keeping many
 introduction connections open or risking such an attack. In this case,
 similar to the authentication tokens, he can provide selected users
 with a current list and/or future schedule of introduction points that
@@ -1325,7 +1325,7 @@
 generally available. Alternatively, Bob could give secret public keys
 to selected users for consulting the DHT\@. All of these approaches
 have the advantage of limiting the damage that can be done even if
-some of the selected high-priority users colludes in the DoS\@.
+some of the selected high-priority users collude in the DoS\@.
 
 
 \SubSection{Integration with user applications}
@@ -1687,10 +1687,9 @@
   he can block access to the service. However, re-advertisement of
   introduction points can still be done secretly so that only
   high-priority clients know the address of the service's introduction
-  points.  Such selective secret authorizations can also be issued
-  during normal operation so that the attack cannot also prevent their
-  issuance.  In this setting an attack must be able to disable all
-  introduction points for all services to be effective.
+  points. These selective secret authorizations can also be issued
+  during normal operation. Thus an attacker must disable
+  all possible introduction points.
 
 \item \emph{Compromise an introduction point.} If an attacker controls
   an introduction point for a service, it can flood the service with
@@ -1719,7 +1718,7 @@
 
 Many of these open issues are questions of balance.  For example,
 how often should users rotate to fresh circuits?  Too-frequent
-rotation is inefficient, expensive and may lead to intersection attacks,
+rotation is inefficient, expensive, and may lead to intersection attacks,
 but too-infrequent rotation
 makes the user's traffic linkable.   Instead of opening a fresh
 circuit; clients can also limit linkability by exiting from a middle point
@@ -1809,7 +1808,7 @@
 %times when Alice is simply not online. Link padding, at the edges or
 %inside the cloud, does not help for this.
 
-In order to scale to large numbers of users, and to prevent an
+In order to scale to many users, and to prevent an
 attacker from observing the whole network at once, it may be necessary
 for low-latency anonymity systems to support far more servers than Tor
 currently anticipates.  This introduces several issues.  First, if
@@ -1945,7 +1944,7 @@
   gain experience in deploying an anonymizing overlay network, and
   learn from having actual users.  We are now at the point in design
   and development where we can start deploying a wider network.  Once
-  we have large numbers of actual users, we will doubtlessly be better
+  we have many actual users, we will doubtlessly be better
   able to evaluate some of our design decisions, including our
   robustness/latency trade-offs, our performance trade-offs (including
   cell size), our abuse-prevention mechanisms, and