[minion-cvs] First cut of first 2/3 of new section 2. Needs major w...

[nickm@seul.org (Nick Mathewson)]

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

Modified Files:
	minion-design.tex 
Log Message:
First cut of first 2/3 of new section 2.  Needs major work still. Need to write attacks section.

Index: minion-design.tex
===================================================================
RCS file: /home/minion/cvsroot/doc/minion-design.tex,v
retrieving revision 1.61
retrieving revision 1.62
diff -u -d -r1.61 -r1.62
--- minion-design.tex	1 Nov 2002 20:15:27 -0000	1.61
+++ minion-design.tex	2 Nov 2002 06:44:48 -0000	1.62
@@ -73,7 +73,7 @@
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
-\section{Overview}
+\section{Introduction}
 \label{sec:intro}
 
 Chaum first introduced anonymous remailers over 20 years ago
@@ -126,7 +126,7 @@
 
 \item \textbf{Replay prevention and key rotation:} ...
 
-\item \textbf{Directory servers:} Mixmaster uses several \emph{ad hoc}
+\item \textbf{Integrated directory servers:} Mixmaster uses several \emph{ad hoc}
 approaches to distributing remailer availability, performance, and
 key information. But the fact that users and remailers operate with
 different information introduces \emph{partitioning} attacks. Mixminion
@@ -164,6 +164,125 @@
 %researchers and Mixmaster remailer operators. This design document
 %represents the first step in peer review of the Type III remailer
 %protocol.
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\section{Overview and background}
+%% This is a new 'overview' section to come after the toplevel
+%% intro; with content as suggested by Roger.  I don't know what we
+%% should rename the intro to.
+%%
+%% Also, the writing here NEEDS to be cleaned up.  -NM
+%
+% What's a MIX-net?
+In a MIX-net, message senders achieve anonymity by routing their
+messages through a path of relay servers, or `MIXes.'  When Alice
+wants to send an anonymous message to Bob through the MIXes $M_1$,
+$M_2$, and $M_3$, she encrypts her message successively with the
+public keys of the mixes in reverse order, and includes routing
+information for each MIX, so that each MIX $M_i$ receives the address
+of $M_{i+1}$ along with the payload intended for $M_{i+1}$, all
+encrypted with $M_i$'s public key.  
+% This is kind of unclear.  Maybe integrate the paragraph from below
+% that says 'mixminion uses the same general MIX-net paradigm...'
+% 
+% needs references, too
+
+% What do MIXes do?
+When a MIX receives a message, it decrypts it with its public key, 
+and delays it according to some `batching rule' so that an observer
+cannot easily associate its outputs with its inputs.  It then sends
+extracts the address of the next MIX in the sequence from the
+decrypted message, and delivers the contents of the message to the
+next MIX.
+
+% XXXX Mention how this provides any anonymity!
+
+% What's a reply block?
+When recipients want to achieve anonymity, some MIX-net designs allow
+them to construct \empf{reply blocks} that allow others to send
+messages to them without knowing their identities.  A reply block
+contains only the routing portion of a message; the actual contents
+are provided by the user that eventually sends a message to the
+recipient.
+
+% How does mixminion fit in?
+Mixminion's principal difference from earlier MIX-net designs is the
+mechanism it uses to support reply messages with the same processing
+machinery as non-reply messages, while at the same time resisting the
+attacks described below in REF.
+% This could be phrasesd far better
+
+\subsection{Design goals and assumptions}
+% this needs more material, and a bit less 'attitude' :)
+
+% Server requirements
+First of all, the system must be relatively simple to deploy.  Past
+systems have never found it easy to get a reliable pool of MIX
+operators to run long-lived servers; Mixminion must add as few
+technical barriers as possible.  Thus, we require that our protocol
+require only loose clock synchronization (within a few minutes);
+that it achieve acceptable performance on commodity hardware, and 
+that it require little coordination between servers.
+
+% Client requriements
+Furthermore, software adoption has also been a barrier to past
+systems. (REF?) Thus, we require that only users who receive anonymity
+from the system need to run special software -- that is, users should
+be able to receive messages from anonymous senders and send messages
+to anonymous recipients without any support beyond a standard email
+client.  Users must also be able to send and receive anonymous
+messages using only commodity hardware.  Finally, although users with
+persistant network connections are necessarily more resistant to
+intersection attacks than users with intermittent connections (see
+REF below), the system must still support users with intermittent
+connections and offer them as much anonymity as possible.
+
+For an adversary model, we assume a well-funded attacker who can
+observe all or most traffic on the network, who can generate, modify,
+delete, or delay traffic on the network, who can operate MIXes of its
+own, and who can compromise some fraction of the MIXes on the network.
+We assume that such an adversary is attempting to compromise users'
+anonymity by learning (or guessing with a reasonable probability) who
+is communicating with whom.
+%What else is the adversary trying to do?
+
+We want to resist
+
+replies: we want to avoid partitioning by having reply messages be
+   indistinguishable from forward messages, and just as secure.  To the
+   extent possible, a MIX should not be able to learn any more from a
+   message's contents than from the fact of the message's receipt.
+
+
+\subsection{Known attacks against MIX-nets}
+
+The largest class of passive attacks against 
+
+-control servers
+-compromise servers
+
+-replay
+
+-delaying
+-dropping
+-textual analysis
+
+-partitioning
+
+-tagging attacks
+
+-(n-1) attack
+
+-directory-related attacks
+
+-flooding attack
+
+-delaying attack
+
+-timing attacks
+
+-intersection attacks
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%