[minion-cvs] incorporating len"s suggestions

[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:
incorporating len's suggestions


Index: minion-design.tex
===================================================================
RCS file: /home/minion/cvsroot/doc/minion-design.tex,v
retrieving revision 1.43
retrieving revision 1.44
diff -u -d -r1.43 -r1.44
--- minion-design.tex	7 May 2002 14:21:16 -0000	1.43
+++ minion-design.tex	8 May 2002 01:22:12 -0000	1.44
@@ -283,9 +283,17 @@
 
 We choose to drop packet-level compatibility with Mixmaster and the
 cypherpunk remailer systems, in order to provide a simple extensible
-design. At the same time, we provide a new feature: a reply block
-mechanism that is as secure as forward messages.
+design. We can retain minimal backwards compatibility by ``remixing''
+Type II messages to be Type III messages, thus increasing the anonymity
+set of the Type III network. Type II messages, when received by a
+remailer capable of understanding both Type II and III and destined for
+a remailer capable of understanding both Type II and III, are treated
+as plaintext and encrypted to the next remailer in the chain using its
+Type III key. The message is then sent as Type III encrypted message,
+and decrypted to reveal the Type II message.
 
+We also provide a new feature: a reply block mechanism that is as secure
+as forward messages.
 Reusable reply blocks, such as those in the cypherpunk remailer, are a
 security risk --- by their very nature they let people send multiple
 messages through them.  These multiple messages can easily be used to
@@ -728,9 +736,10 @@
 \subsection{Message types and delivery modules}
 \label{subsec:delivery-modules}
 
-Once a Mixminion packet reaches the final MIX in its path, it must
-either be delivered to its intended recipient, or dropped if it's an
-intra-network dummy message. In order to support different kinds of
+Once a Mixminion packet reaches the final MIX in its path, it must either
+be delivered to its intended recipient, dropped if it's an intra-network
+dummy message, or processed further if it is a remixed Type II packet.
+In order to support different kinds of
 delivery, the header includes a type code for the action to be taken
 to deliver the message.  A few types --- such as `dummy', `SMTP', and
 `local delivery' --- are specified as a part of the Mixminion
@@ -781,8 +790,8 @@
 
 The types each MIX supports are described in a \emph{capability block},
 which also includes the MIX's address, long-term (signing) public key,
-short-term key (for use in header encryption), and batching strategy.
-MIXes sign these capability blocks
+short-term key (for use in header encryption), remixing capability and
+batching strategy. MIXes sign these capability blocks
 and publish them on directory servers (see Section \ref{sec:dir-servers}).
 Clients download this information from the directory servers.