[freehaven-cvs] Grammar/clarity improvements (thanks arma, Ben).

[rabbi@seul.org]

Update of /home2/freehaven/cvsroot/doc/mixmaster-vs-reliable
In directory moria.mit.edu:/tmp/cvs-serv21476

Modified Files:
	mixvreliable.tex 
Log Message:
Grammar/clarity improvements (thanks arma, Ben).


Index: mixvreliable.tex
===================================================================
RCS file: /home2/freehaven/cvsroot/doc/mixmaster-vs-reliable/mixvreliable.tex,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -d -r1.33 -r1.34
--- mixvreliable.tex	1 Jul 2004 08:12:39 -0000	1.33
+++ mixvreliable.tex	1 Jul 2004 09:20:47 -0000	1.34
@@ -25,23 +25,23 @@
 We evaluate the anonymity provided by two popular email mix
 implementations, Mixmaster and Reliable, and compare their effectiveness
 through the use of simulations which model the algorithms used by these
-mixing applications. In order to draw accurate conclusions about the
-operation of these mixes, we use as our input to these simulations actual
-traffic data obtained from a public anonymous remailer (mix node). We
-determine that assumptions made in previous literature about the
-distribution of mix input traffic are incorrect, and our analysis of the
-input traffic shows that it does not follow a Poisson distribution. We establish for
-the first time that a lower bound exists on the anonymity of Mixmaster, and
-discover that under certain circumstances the algorithm used by Reliable
-provides no anonymity. We find that the upper bound on anonymity provided
-by Mixmaster is slightly higher than that provided by Reliable. We identify
-flaws in the software code in Reliable that further compromise its ability
-to provide anonymity, and review key areas which are necessary for the
-security of a mix in addition to a sound algorithm. Our analysis can be
-used to evaluate under which circumstances the two mixing algorithms should
-be utilized to best achieve anonymity and satisfy their purpose. Our work
-can also be used as a framework for establishing a security review process
-for mix node deployments.
+mixing applications. Our simulations are based on actual traffic data
+obtained from a public anonymous remailer (mix node). We determine that
+assumptions made in previous literature about the distribution of mix
+input traffic are incorrect: in particular, the input traffic does not
+follow a Poisson distribution. We establish for the first time that a
+lower bound exists on the anonymity of Mixmaster, and discover that under
+certain circumstances the algorithm used by Reliable provides no
+anonymity. We find that the upper bound on anonymity provided by Mixmaster
+is slightly higher than that provided by Reliable.
+
+We identify flaws in the software in Reliable that further compromise
+its ability to provide anonymity, and review key areas which are necessary
+for the security of a mix in addition to a sound algorithm. Our analysis
+can be used to evaluate under which circumstances the two mixing
+algorithms should be used to best achieve anonymity and satisfy their
+purpose. Our work can also be used as a framework for establishing a
+security review process for mix node deployments.
 
 \end{abstract}
 
@@ -82,10 +82,10 @@
 traffic. In order to make messages indistinguishable from each other the
 mix uses techniques such as padding and encryption, which provide bitwise
 unlinkability between inputs and outputs. Techniques such as reordering
-and delaying messages, and generating dummy traffic are used to modify the
+messages delaying them, and generating dummy traffic are used to modify the
 flow of messages. This modification of the traffic flow is needed to
-prevent timing attacks that could disclose the relationship between an
-input and an output messages by observing the time the message arrived at
+prevent timing attacks that could disclose the relationship between
+input and output messages by observing the time the messages arrived at
 and left from the mix.
 
 The idea of mixes was introduced by Chaum~\cite{chaum-mix}.  This first
@@ -123,7 +123,7 @@
 placed in the pool of the mix. When the timeout expires, the mix takes
 a number of messages from the pool that are forwarded to their next
 destination, which may be another mix or a final recipient. 
-The algorithm that determines the number $s$ of messages that are sent
+The number $s$ of messages sent
 in a \emph{round} (one cycle of the mix) is a function of the number
 $n$ of messages in the pool:
 \begin{verbatim}
@@ -132,11 +132,11 @@
 else s=0.65*n;
 \end{verbatim}
 
-Mixmaster is represented in the generalized mix model proposed by
+Mixmaster is represented in the generalized mix model (GMM) proposed by
 D\'iaz and Serjantov~\cite{DS03} as shown in
 Figure~\ref{fig-mm}. In this model, the mix is represented at the time of
-flushing. The function $P(n)$ represents the probability of a message
-of being flushed by the mix, as a function of the number $n$ of
+flushing. The function $P(n)$ represents the probability that a message is
+flushed by the mix, as a function of the number $n$ of
 messages in the pool. Note that $P(n)=s/n$.
 \begin{figure}
 \begin{center}
@@ -156,8 +156,8 @@
 \emph{continuous mixes}), the users generate a random delay from an
 exponential distribution. The mix holds the message for the specified
 delay and then forwards it. The messages are reordered by the randomness
-of the delay distribution. This mix sends messages continuously: every
-time a message has been kept for the delay time it is sent out by the mix.
+of the delay distribution. This mix sends messages continuously: when it
+has been kept for the delay time it is sent out by the mix.
 
 Reliable interoperates with Mixmaster on the protocol level by using the
 Mixmaster message format for packet transfer. Reliable uses a variant of
@@ -170,26 +170,25 @@
 implement this feature given that it interoperates in a network with pool
 mixes, whose delays are unpredictable (these timestamps can only be
 effectively utilized if the whole chain of mixes is S-G and the user is
-choosing the delay for each hop in the path). Reliable, thus, does not
+choosing the delay for each hop in the path). Reliable thus does not
 provide any resistance to this kind of active attack.}
 
-In Reliable, the delay may be chosen by the user from an exponential
-distribution of mean one hour. If the user does not provide any delay to
-the mix, then the mix itself picks a delay from a uniform distribution,
-being the maximum and minimum of the uniform one and four hours,
-respectively. Note that these parameters of the delay distributions are
-configurable, and therefore many remailer operators may set them lower in
-order to provide a faster service.
+In Reliable, the delay may be chosen by the sender from an exponential
+distribution of mean one hour. If the sender does not provide any delay to
+the mix, then the mix itself picks a delay from a uniform distribution of
+one and four hours. Note that these parameters of the delay distributions
+are configurable, and therefore many remailer operators may set them lower
+in order to provide a faster service.
 
 
 \subsection{Dummy traffic}
 \label{dummy}
 
 A dummy message is a \emph{fake} message introduced into the mix network
-in order to make it more difficult for an attacker to deploy attacks that
-can compromise the anonymity of a message. The dummy messages are produced
-by the mixes, and use a chain of mix nodes that terminates at a final mix
-instead of a real recipient.
+to make it more difficult for an attacker to deploy attacks that
+compromise the anonymity of a message. The dummy messages are produced by
+the mixes, and use a chain of mix nodes that terminates at a mix instead
+of a real recipient.
 
 Dummies are indistinguishable from real messages as they travel in the
 mix network. Since they are introduced to prevent traffic analysis, the

***********************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe freehaven-cvs       in the body. http://freehaven.net/