[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[freehaven-cvs] Fixed some grammar issues, typos.
Update of /home2/freehaven/cvsroot/doc/mixmaster-vs-reliable
In directory moria.mit.edu:/tmp/cvs-serv19598
Modified Files:
mixvreliable.tex
Removed Files:
expCDFsubplots.eps
Log Message:
Fixed some grammar issues, typos.
--- expCDFsubplots.eps DELETED ---
Index: mixvreliable.tex
===================================================================
RCS file: /home2/freehaven/cvsroot/doc/mixmaster-vs-reliable/mixvreliable.tex,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -d -r1.19 -r1.20
--- mixvreliable.tex 30 Jun 2004 18:58:51 -0000 1.19
+++ mixvreliable.tex 30 Jun 2004 22:29:31 -0000 1.20
@@ -156,39 +156,37 @@
\subsection{Reliable}
-Reliable is based on the Stop-and-Go (\emph{SG Mix}) mix proposed by
-Kesdogan \emph{et al.} in \cite{stop-and-go}. In SG mixes (also called
+Reliable is loosely based on the Stop-and-Go (\emph{SG Mix}) mix proposed
+by Kesdogan \emph{et al.} in \cite{stop-and-go}. In SG mixes (also called
\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.
-
-The theoretical S-G mix design assumes that the delay parameter adapts
-to the traffic load, that is, the mix should set the delay parameter
-according to the amount of input traffic it is receiving. This feature
-is not implemented in Reliable, that has a static delay
-parameter. Another feature of S-G mixes is that they implement
-timestamps in order to prevent active attacks ($n-1$ attacks in
-particular). Reliable does not implement this feature given that it
-interoperates in a network with pool mixes, whose delays are
-unpredictable (these timestamps can only be generated 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 provide any resistance to
-this kind of active attacks.
-
+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.
Reliable interoperates with Mixmaster on the protocol level by using the
Mixmaster message format for packet transfer. Reliable uses a variant of
-the \emph{S-G mix} design. 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.
+the \emph{S-G mix} design.
+
+The theoretical S-G mix design assumes that the delay parameter adapts to
+the traffic load, that is, the mix should set the delay parameter
+according to the amount of input traffic it is receiving. This feature is
+not implemented in Reliable, which has a static delay parameter. True S-G
+mixes also implement timestamps in order to prevent active attacks ($n-1$
+attacks in particular). Reliable cannot implement this feature given that
+it interoperates in a network with pool mixes, whose delays are
+unpredictable (these timestamps can only be generated 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 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.
\subsection{Dummy traffic}
@@ -222,10 +220,10 @@
\paragraph{Dummy policy of Reliable}
-Reliable's default dummy policy consists in generation $25$ dummies
-every 6 hours. The time these dummies are kept in the mix is generated
-from a uniform distribution whose minimum value is $0$ and maximum is
-$6$ hours.
+Reliable's default dummy policy consists of the generation of $25$ dummies
+every 6 hours. The time these dummies are kept in the mix is selected from
+a uniform distribution whose minimum value is $0$ and maximum is $6$
+hours.
@@ -318,7 +316,7 @@
paper.}. We have assumed
users choose their delays from an exponential distribution. The
mix-chosen uniform delay option has not been taken into account, due
-to the unfeasibility of implementing algorithms that compute the
+to the infeasibility of implementing algorithms that compute the
anonymity for such a delay distribution without making assumptions on
the traffic pattern, as explained in
Appendix~\ref{form-reliable}. Moreover, the choice of a uniform delay for
@@ -450,12 +448,12 @@
(arrivals) is low. As the traffic increases, anonymity increases,
getting maximum values of about $10$ (i.e., equivalent to perfect
indistinguishability among $2^{10}=1024$) senders or recipients.
-We also observe that the delays of the messages don't take hight
+We also observe that the delays of the messages don't take high
values, unless the traffic load getting to the mix is very low.
In order to study the behaviour of the mix under different traffic loads,
we have plotted values of delay and anonymity obtained in the simulation
-for the rounds with few arrivals (low traffic), intermediate number of
+for the rounds with few arrivals (low traffic), intermediate number of
arrivals (medium traffic) and many arrivals (high traffic).
We have selected the low, medium and high traffic taking into account
@@ -512,9 +510,9 @@
is definitely not correct for mix traffic.
We have simulated a Reliable mix as explained in
-Section~\ref{sims}. Reliable is a continuous (stop-and-go) mix.
+Section~\ref{sims}.
Reliable treats every message independently: when it gets a message
-it delays it a pre-determined amount of time (picked from an exponential
+it delays it a predetermined amount of time (picked from an exponential
distribution) and then forwards it. We represent a star, '*', per message.
In figure~\ref{rel-sen} we present the sender and recipient anonymity
@@ -651,11 +649,11 @@
The software packages we evaluated differed with regard to their interface
complexity in a number of areas.
-In general, Reliable has a greater "ease of use" factor with respect to
+In general, Reliable has a greater ``ease of use'' factor with respect to
its interface. Mixmaster automates many important tasks, such as adaptive
dummy generation, key rotation and key expiration announcement, and
-integrates more easily with the host MTA~\footnote{Mail Transport Agent,
-e.g. sendmail or postfix}. Reliable's installation process is easier, but
+integrates more easily with the host MTA.\footnote{Mail Transport Agent,
+e.g. sendmail or postfix} Reliable's installation process is easier, but
its build process requires the use of third-party commercial applications
and assumes experience with Windows development, so most users will
install a pre-compiled binary. Compilation of Mixmaster is performed
@@ -701,7 +699,7 @@
OS, Mixmaster 3.0, the version of Mixmaster evaluated in this paper,
requires that the zlib~\cite{rfc-1950} and OpenSSL~\cite{OpenSSL}
libraries be included. Optionally, Mixmaster also links against
-pcre~\cite{pcre} an ncurses~\cite{ncurses}.
+pcre~\cite{pcre} and ncurses~\cite{ncurses}.
Reliable requires many native Windows system calls as well as the
third-party application, Mixmaster 2.0.4.
@@ -855,9 +853,9 @@
that may have occurrences of low traffic on the network. While
Reliable mixes may be an appropriate solution for systems with a
steady input rate, they are not suited for systems with variable input
-traffic. Misxmaster should be used for systems with fluctuating
+traffic. Mixmaster should be used for systems with fluctuating
traffic loads.
-.
+
%%% end input Len
\subsection*{Acknowledgments}
***********************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe freehaven-cvs in the body. http://freehaven.net/