[freehaven-cvs] Fix formatting, more S-G clarification.

[rabbi@seul.org]

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

Modified Files:
	mixvreliable.tex 
Log Message:
Fix formatting, more S-G clarification.


Index: mixvreliable.tex
===================================================================
RCS file: /home2/freehaven/cvsroot/doc/mixmaster-vs-reliable/mixvreliable.tex,v
retrieving revision 1.48
retrieving revision 1.49
diff -u -d -r1.48 -r1.49
--- mixvreliable.tex	1 Jul 2004 11:40:37 -0000	1.48
+++ mixvreliable.tex	1 Jul 2004 17:11:43 -0000	1.49
@@ -1,4 +1,4 @@
-\documentclass{article}
+\documentclass[runningheads]{llncs}
 \usepackage{amsmath, amssymb}
 \usepackage{epsfig}
 \usepackage{latexsym}
@@ -8,7 +8,17 @@
 
 \title{Comparison between two practical mix designs}  
 
-\author{Claudia D\'{\i}az \and Len Sassaman \and Evelyne Dewitte}
+\author{Claudia D\'{\i}az\inst{1} \and Len Sassaman\inst{2} \and Evelyne Dewitte\inst{1}}
+
+%foo
+
+\institute{K. U. Leuven ESAT-COSIC \\
+Kasteelpark Arenberg 10, B-3001 Leuven-Heverlee, Belgium
+\email{\{claudia.diaz,dewitte\}@esat.kuleuven.ac.be}
+\and
+{\tt rabbi@abditum.com}}
+
+%foo
 
 \bibliographystyle{alpha}
 
@@ -161,21 +171,22 @@
 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.\footnote{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). Previous work has
-argued that this method is unlikely to be effective~\cite{sds}.
-Regardless, as the message protocol was originally designed with only a
-pool mix network in mind, these timestamps are not used, nor is it clear
-that they could be utilized effectively since the sender is choosing the
-delay for each hop in the path. Reliable thus does not provide any
-resistance to this kind of active attack.}
+that the delay parameter adapts to the traffic load, that is, the users
+should set the delay parameter according to the amount of input traffic
+the mix 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). Previous
+work has argued that this method is unlikely to be effective, since the
+senders be able to determine the appropriate delay for each mix in the
+path~\cite{sds}. True S-G mixes would require a service provide such
+information. Regardless, as the message protocol was originally designed
+with only a pool mix network in mind, these timestamps are not used.
+Reliable thus does not provide any resistance to this kind of active
+attack.}
 
 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 \em{uniform} distribution of
+the mix, then the mix itself picks a delay from a \emph{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
 to provide a faster service.
@@ -320,7 +331,7 @@
 the transitory initial and final phases. In our simulations, the
 number of rounds discarded in the initial phase is $3$, and the number
 of rounds discarded in the final phase is $39$. The total number of
-rounds for our input traffic is $11,846$.  
+rounds for our input traffic is $11846$.  
 
 \section{Results}
 \label{results}
@@ -352,7 +363,7 @@
 of arrivals per time interval $\Delta t = 15$ minutes ($N=11800$). We also
 constructed a $95$\% confidence interval for this estimate. In this way we
 found
-$\hat{\lambda} = 19,972$ with confidence region $[19,891 ; 20,052]$.  Then we
+$\hat{\lambda} = 19972$ with confidence region $[19891 ; 20052]$.  Then we
 performed a goodness-of-fit test to determine if we can reject the hypothesis
 \begin{equation*}
 H_0: \mathrm{the\ number\ of\ arrivals\ per\ time\ interval\ } \sim\ \mathrm{Poiss}(\bar\lambda)\ ,
@@ -360,7 +371,7 @@
 where $\bar{\lambda}$ varies over the constructed confidence
 interval. The goodness-of-fit test we used is the well-known Chi-square
 test (df=$n-1$=$11802$).  Using a significance level of $0.01$, the null
-hypothesis gets rejected (Chi-value=$826,208$)! 
+hypothesis gets rejected (Chi-value=$826208$)! 
 % END (Evelyne)
 
 In the left part of Figure~\ref{arr-day} we show the number of messages
@@ -533,7 +544,7 @@
 %\includegraphics[width=5cm, height=3cm]{/users/sista/dewitte/PHD/papers/source/sen-rec.eps}
 \includegraphics[height=6cm]{source/sen-rec.eps}
 \includegraphics[height=6cm]{source/PlotCorr_Send_Recip_Message.eps}
-\caption{Correlation Sender-Recipient anonymity for Reliable and Mixmaster}
+\caption{Correlation Sender-Recipient Anonymity for Reliable and Mixmaster}
 \label{sen-rec}
 \end{figure}
 
@@ -744,10 +755,10 @@
 format specifies the use of random data for its message and header
 padding.
 
-All software is dependent on its underlying operating system for a good
-source of entropy. Cryptographic quality entropy is a scarce resource on
-most systems,\footnote{Systems that employ the use of noisy diodes or
-other plentiful sources of entropy have less of a concern for entropy pool
+Software is dependent on its underlying operating system for a good source
+of entropy. Cryptographic quality entropy is a scarce resource on most
+systems,\footnote{Systems that employ the use of noisy diodes or other
+plentiful sources of entropy have less of a concern for entropy pool
 exhaustion.} and therefore the entropy sources provided by most modern
 operating systems actually provide PRNG output which has been seeded with
 truly-random data.
@@ -810,14 +821,14 @@
 randomness in Reliable, which diminishes its ability to provide anonymity,
 independent of our findings with regard to the S-G mix protocol.
 
-
 We can conclude from our analysis of the mixing algorithms used by these
 mix implementations that S-G mix variants such as the one used in Reliable
 are not suitable for use with systems that may have occurrences of low
-traffic on the network. While S-G mixes may be an appropriate
+traffic on the network. While such S-G mixes may be an appropriate
 solution for systems with a steady input rate, they are not suited for
-systems with variable input traffic. Pool mixes such as Mixmaster
-should be used for systems with fluctuating traffic loads.
+systems with variable input traffic. Pool mixes such as Mixmaster should
+be preferred for systems with fluctuating traffic loads and relaxed
+latency contraints.
 
 \subsection*{Acknowledgments}
 

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