[minion-cvs] addressed some comments from wouter

[arma@seul.org (Roger Dingledine)]

Update of /home/minion/cvsroot/doc
In directory moria.seul.org:/home/arma/work/minion/doc

Modified Files:
	minion-design.tex 
Log Message:
addressed some comments from wouter


Index: minion-design.tex
===================================================================
RCS file: /home/minion/cvsroot/doc/minion-design.tex,v
retrieving revision 1.41
retrieving revision 1.42
diff -u -d -r1.41 -r1.42
--- minion-design.tex	7 May 2002 13:13:01 -0000	1.41
+++ minion-design.tex	7 May 2002 14:19:28 -0000	1.42
@@ -48,7 +48,8 @@
 
 
 \maketitle
-\pagestyle{empty} 
+\pagestyle{plain} 
+% IH2002 wants page numbers
   
 \begin{abstract}
 
@@ -106,7 +107,9 @@
 rather than just allowing delivery to mail or Usenet, we allow designers
 to add arbitrary modules to handle incoming and outgoing messages. By
 separating the core mixing architecture from these higher-level modules,
-we can limit their influence on the anonymity properties of the system. We
+we can both limit their influence on the anonymity properties of the
+system, and also extend the Mixminion network for uses other than
+anonymous email. We
 go on in Section \ref{sec:dir-servers} to describe a design for directory
 servers to track and distribute remailer availability, performance,
 and key information, and then describe in Section \ref{sec:nymservers}
@@ -252,8 +255,9 @@
 to the node that can be used to generate padding and decrypt the rest
 of the message. They also contain the address of the next node to 
 which to message should be forwarded along with its expected signature 
-key fingerprint. In order to frustrate tagging attacks (as described later
-in the paper) the sub-header also contains a hash of the header that
+key fingerprint. In order to frustrate tagging attacks (see
+Section \ref{subsec:tagging}) the sub-header also contains a hash of
+the header that
 should be checked. 
 
 % This last paragraph assumes that the audience already knows the
@@ -288,10 +292,11 @@
 trace the recipient's path: if two incoming batches both include a
 message to the same reply block, then the next hop must be in the
 intersection of both outgoing batches.  To prevent these replays,
-Mixminion therefore provides only \emph{single-use} reply
-blocks. Further, the Mixminion protocol makes reply messages
-indistinguishable from forward messages, allowing forward and reply
-messages to share the same anonymity set.
+Mixminion therefore provides only \emph{single-use} reply blocks. Since
+replies may be very rare relative to forward messages, and thus
+much easier to trace, the Mixminion protocol makes reply messages
+indistinguishable from forward messages. Thus forward and reply messages
+can share the same anonymity set.
 
 \subsection{Batching Strategy and Network Structure}
 \label{subsec:batching}
@@ -696,7 +701,8 @@
 have been deleted, not even the
 nodes that exchange messages can decrypt or recognize messages
 that might have been intercepted on the links. This makes it
-impossible to comply with decryption notices that might be served in
+impossible to comply with decryption notices of past traffic 
+that might be served in
 some jurisdictions.  
 It also forces adversaries to 
 corrupt and control nodes in order trace