[minion-cvs] removed the three paragraphs david (accidentally?) adde...

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

Modified Files:
minion-design.tex
Log Message:
removed the three paragraphs david (accidentally?) added back.

let me know if you wanted them to actually be there, david :)

Index: minion-design.tex
===================================================================
RCS file: /home/minion/cvsroot/doc/minion-design.tex,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -d -r1.29 -r1.30
--- minion-design.tex	6 May 2002 04:53:35 -0000	1.29
+++ minion-design.tex	6 May 2002 05:19:40 -0000	1.30
@@ -73,7 +73,7 @@
Chaum first introduced anonymous remailer designs over 20 years ago
\cite{chaum-mix}. The research community has since introduced many new
designs and proofs
-\cite{abe,web-mix,babel,flash-mix,realtime-mix,kesdogan,hybrid-mix},
+\cite{abe,web-mix,babel,flash-mix,realtime-mix,kesdogan,shuffle,hybrid-mix},
and discovered a variety of new attacks
but the state of deployed remailers has changed remarkably little since
@@ -406,7 +406,7 @@
to create onions, and receivers must be able to create reply blocks
such as those receiving forward messages and those sending direct reply
-messages, do not need to run any new software.
+messages, do not need to run new software.

% Do we ever say how to send a reply without software? -Nick
% Nope. We're just bluffing. Is that ok? -RRD
@@ -448,42 +448,42 @@
\end{center}
\end{figure}

-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 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.
-
-The packet travels through nodes that perform the operations illustrated
-on \emph{figure 1}. Each node decrypts the RSA sub header, retrieves
-the key and checks the integrity of the first header. If someone has
-tampered with it, the packet is discarded. If the header is correct,
-the secret is used to decrypt the second header and the payload. There
-is one special node, at the crossover point'' in the path, that in
-
-The primitive used for encryption and decryption is BEAR \cite{BEAR},
-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 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
-afterward the first part of the path should offer enough anonymity. Of
-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 remaining tagging attack provides very little information
-and is very difficult to mount.
+%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 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.
+%
+%The packet travels through nodes that perform the operations illustrated
+%on \emph{figure 1}. Each node decrypts the RSA sub header, retrieves
+%the key and checks the integrity of the first header. If someone has
+%tampered with it, the packet is discarded. If the header is correct,
+%the secret is used to decrypt the second header and the payload. There
+%is one special node, at the crossover point'' in the path, that in
+%
+%The primitive used for encryption and decryption is BEAR \cite{BEAR},
+%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 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
+%afterward the first part of the path should offer enough anonymity. Of
+%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 remaining tagging attack provides very little information
+%and is very difficult to mount.

Because the path is split into two legs, we can cleanly support anonymized
reply messages. Alice simply uses Bob's reply block as the second leg,
@@ -559,15 +559,16 @@
attack. If Alice sends a group of messages along the same path, the
adversary can tag some of those message as they leave Alice, recognize
the pattern (number of tagged and untagged messages) at the crossover
-point, and observe where the untagged ones go.
+point, and observe where the untagged ones go (if he built the second
+leg himself, as in an anonymized reply, he can recognize it immediately).

-It turns out with some assumptions about our adversary, we can reduce
this attack to a traffic confirmation attack we're already willing to
accept: when Alice sends a bunch of messages, the adversary can count
them and look for the pattern later. He can also drop some of them and
look for resulting patterns.

-The attack is possible only if the adversary happens to own the crossover
+The adversary can only recognize a tag if he happens to own the crossover
point that Alice chooses.
% If Alice were sending
%only one message, then this multiple-message tagging attack also would
@@ -860,10 +861,10 @@
--- he can then release the delayed messages and guess that any messages
still using $M$ are likely to be from Alice. An adversary controlling
many nodes can launch this attack very effectively. Thus clients