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

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,
@@ -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. In the case of a bi-directional anonymous channel the
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
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
% 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}).

% 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}

`