[minion-cvs] Added the design principle that nodes should not know w...

[gd@seul.org]

Update of /home/minion/cvsroot/doc
In directory moria.seul.org:/tmp/cvs-serv7195

Modified Files:
	minion-design.tex 
Log Message:
Added the design principle that nodes should not know where
they are on the path and the total length (that should keep
the Dresden group happy)

Corrected some small typos (changes the "eight years ago" to "1994").



Index: minion-design.tex
===================================================================
RCS file: /home/minion/cvsroot/doc/minion-design.tex,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -d -r1.16 -r1.17
--- minion-design.tex	3 May 2002 04:44:27 -0000	1.16
+++ minion-design.tex	3 May 2002 20:07:54 -0000	1.17
@@ -56,7 +56,7 @@
 
 \end{abstract}
 
-Keywords: anonymity, MIX-net, peer-to-peer, remailer, nymserver, reply block %, ...
+\textbf{Keywords:} anonymity, MIX-net, peer-to-peer, remailer, nymserver, reply block %, ...
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
@@ -68,8 +68,8 @@
 designs and proofs \cite{big-chain-of-cites}, and discovered a variety
 of new attacks \cite{more-cites}, but the
 state of deployed remailers has changed remarkably little since Cottrell
-published his Mixmaster software \cite{mixmaster-attacks} eight years
-ago. Part of the difficulty in expanding the deployed remailer base is
+published his Mixmaster software \cite{mixmaster-attacks} in 1994. 
+Part of the difficulty in expanding the deployed remailer base is
 due to the liability involved in running a remailer node on the Internet,
 and part is due to the complexity of the current infrastructure ---
 it is very hard to add new experimental features to the current software.
@@ -93,7 +93,8 @@
 ensure forward anonymity for each message. We also provide flexible
 delivery schemes --- rather than just allowing delivery to mail or
 Usenet, we allow designers to add arbitrary modules to handle incoming
-messages. By separating the core mixing architecture from these
+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.
 
@@ -221,13 +222,26 @@
 We chose to drop backward-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.
+is as secure as forward messages. Despite that in order to facilitate
+deplayment we only require the parties that benefit from anonymity 
+properties to run dedicated software to be able to communicate with 
+the remailer network. Only senders are therefore required to have special
+clients in case of forward messages, and receivers in the case of SURBs.
 
 Reusable reply blocks are security risks --- by their very nature they
 let people send multiple messages to them. These multiple messages can be
 used to very quickly 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.
+be in the intersection of both outgoing batches. For these reasons 
+mixminion only supports single use reply blocks.
+
+One of the objectives of mixminion is to minimize the traffic analysis 
+value any compromised node could extract form passing messages. The 
+message format is such that processing is possible without leaking the
+position of the intermediary node in the chain or the total length
+of the route. Exceptions to this are exit nodes, where a route ends, 
+and in the case of the ``swap headers'' method, described below, the
+the node that performs the crossover.
 
 %Mixmaster solves the problem by not providing reply functionality,
 %and instead falling back on the less secure multiple-use reply blocks
@@ -274,12 +288,13 @@
 A ``header swap'' mechanism could be used in order to minimize the
 information leaked by \emph{tagging attacks}. Each mixminion packet,
 when created, has two headers: the first one contains a series of sub
-headers encrypted as an onion under the public keys of a sequence of
+headers each encrypted as an onion under the public keys of a sequence of
 nodes. Each of these sub headers contain some symmetric key and a hash
 to check the integrity of the header. The second header contains sub
 headers in the form of an onion as well but is also encrypted under
 the keys contained in the first header, as well as the hash of the
-payload. The second header could also be a single use reply block (SURB)
+payload. In the case of a bi-directional anonymous channel the 
+second header could also be a single use reply block (SURB)
 provided by another party. The payload is finally encrypted using all
 the keys contained in the first header and the second if it is not a SURB.
 
@@ -296,7 +311,7 @@
 a variable block size block cipher. It offers the property that if any
 bit of the encrypted material is changed the decryption will look like
 random bits for anyone that does not know the key. Therefore we minimize
-an attackers benefit for tagging the message. It is impossible to tag the
+an attackers benefit from tagging a message. It is impossible to tag the
 headers because any modification is detectable. It is also fruitless to
 modify the payload of the message: if it is modified before the crossover
 point, the second header will not be decryptable, and if it is modified
@@ -304,8 +319,8 @@
 course in order to make this scheme as secure as if tagging attacks did
 not exist we should require users to choose the double path length for
 each message. In practice users might choose to select shorter paths,
-given that the tagging attack provides very little information and is
-very difficult to mount.
+given that the remaining tagging attack provides very little information 
+and is very difficult to mount.
 
 \subsection{Approach two: the `distinguish replies' method}
 \label{subsec:distinguish-replies}
@@ -323,11 +338,12 @@
 ephemeral key could be signed by the receiving node. As soon as a
 session key has been established the Diffie-Hellman keys are destroyed
 and messages start being sent through the tunnel. After each message a
-standard key update operation is performed to generate a new key and
+standard key update operation is performed to generate a fresh key and
 the old key material is deleted. Key updates don't use any asymmetric
-encryption techniques, so they are quite fast.
+encryption techniques, so they are fast.
 
-The above scheme offers forward secrecy in the sense that even the
+The above scheme offers forward secrecy in the sense that after the keys
+have been deleted even the
 nodes that exchange messages are not able to decrypt or even recognize
 messages that might have been intercepted on the links. This makes it
 impossible to comply with decryption notices that might be served in
@@ -369,7 +385,7 @@
 be different for senders who have obtained an address from different
 sources, leading to a reduction in anonymity sets.}
 In our current design, this information is placed
-in a variable-length annex to the final header.\footnote{It must be
+in a variable-length annex to the final header\footnote{It must be
 in the header, since putting delivery information in the payload would
 prevent people from creating SURBs that can be delivered by SMTP.
 On the one hand, under the ``header swap'' method described in
@@ -377,9 +393,9 @@
 the generator of a reply block from putting any information in the
 payload.  On the other hand, under the ``distinguish replies'' method
 in \ref{subsec:distinguish-replies}, the delivery information would
-create a portion of the payload that the final node {\it could}
+create a portion of the payload that the final node it could
 distinguish from random garbage, thus allowing a tagging attack
-against the reply block.}
+against the reply block.}.
 % See my messages of April 9 and 10 titled ``SMTP service'' for a more
 % detailed version of the above argument. -Nick
 %
@@ -394,7 +410,7 @@
 block}, which also includes the MIX's address, long-term (signing)
 public key, short-term key (for use in header encryption), and
 forwarding strategy (if any).  MIXes sign these capability blocks, and
-publish them on directory servers (see \ref{sec:dir-servers}).
+publish them on directory servers (see section \ref{sec:dir-servers}).
 Clients download this information from the directory servers.
 
 % Is all of the stuff above really in the caps block?  Or do we break
@@ -444,7 +460,7 @@
   to the addressee telling him to send back the signed form if he wanted
   to receive such mail. The government maintained a list of citizens
   who had filled out these forms.
-} Similarly, if receiving mail is opt-out, an abuser can deny service
+}. Similarly, if receiving mail is opt-out, an abuser can deny service
 by forging an opt-out request from a legitimate user. We might instead
 keep the mail at the exit node and send a note to the recipient
 telling them how to collect their mail; but this increases
@@ -571,7 +587,8 @@
 A more robust design uses an IMAP-like protocol: messages arrive and queue
 at the nymserver, and the user periodically checks the status of his mail
 and sends a sufficient batch of reply blocks so the nymserver can deliver
-that mail. The above flooding attack still works, but now it is exactly
+that mail. In that case the nym server can choose not to store any reply block.
+The above flooding attack still works, but now it is exactly
 like flooding a normal IMAP mailbox, and the usual techniques (e.g.,
 allowing the user to delete mails at the server or specify which mails to
 download and let the others expire) work fine. The user can send a set
@@ -740,7 +757,11 @@
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
-\bibliographystyle{plain} \bibliography{minion-design}
+\bibliographystyle{plain}
+
+\bibliography{minion-design}
+
+
 
 \end{document}