[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[freehaven-cvs] Grammar fixes.

To: freehaven-cvs@freehaven.net
Subject: [freehaven-cvs] Grammar fixes.
From: rabbi@seul.org
Date: Thu, 1 Jul 2004 02:49:55 -0400 (EDT)
Delivered-to: archiver@seul.org
Delivered-to: freehaven-cvs-outgoing@seul.org
Delivered-to: freehaven-cvs@seul.org
Delivery-date: Thu, 01 Jul 2004 02:50:09 -0400
Reply-to: freehaven-dev@freehaven.net
Sender: owner-freehaven-cvs@freehaven.net
Update of /home2/freehaven/cvsroot/doc/mixmaster-vs-reliable
In directory moria.mit.edu:/tmp/cvs-serv14529

Modified Files:
	mixvreliable.tex 
Log Message:
Grammar fixes.


Index: mixvreliable.tex
===================================================================
RCS file: /home2/freehaven/cvsroot/doc/mixmaster-vs-reliable/mixvreliable.tex,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -d -r1.29 -r1.30
--- mixvreliable.tex	1 Jul 2004 02:10:46 -0000	1.29
+++ mixvreliable.tex	1 Jul 2004 06:49:53 -0000	1.30
@@ -1,4 +1,4 @@
-\documentclass{article}
+\documentclass{llncs}
 %\usepackage{usenix}
 %Commented out the usenix package since i don't have it -- rabbi
 \usepackage{amsmath, amssymb}
@@ -51,12 +51,12 @@
 
 The Internet was initially perceived as a rather anonymous environment.
 Nowadays, we know that it can be a powerful surveillance tool: anyone
-willing to listen to the communication links can spy on Internet users,
+capable of listening to the communication links can spy on Internet users,
 and search engines and data mining techniques are becoming increasingly
 powerful.
 
-Privacy does not only mean confidentiality of the information; it also
-means not revealing information about who is communicating with whom.
+Preserving privacy does not only mean keeping information confidential; it
+also means not revealing information about who is communicating with whom.
 Anonymous remailers (also called \emph{mixes}) allow their users to send
 emails without disclosing the identity of the recipient to a third party.
 They also allow the sender of a message to stay anonymous to the
@@ -74,23 +74,19 @@
 remailer, and simulated the behavior of the mix.
 
 
-% (Len) Summary of what we have done
-
-% (Len) Roadmap of the paper
-
 \section{Mixes}
 \label{mixes}
 
-Mixes are the essential building block to provide anonymous email
-services. A mix is a router that hides the relationship between incoming
-and outgoing messages. The mix changes the appearance and the flow of the
-messages. In order to change the appearance of the messages the mix uses
-some techniques, such as padding and encryption, thus providing bitwise
-unlinkability between inputs and outputs. Techniques like reordering and
-delaying messages, and generating dummy traffic are used to modify the
+Mixes are the essential building block of anonymous email services. A mix
+is a router that hides the relationship between incoming and outgoing
+messages. The mix changes the appearance and the flow of the message
+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
 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 looking at the time the message arrived to
+input and an output messages by observing the time the message arrived at
 and left from the mix.
 
 The idea of mixes was introduced by Chaum~\cite{chaum-mix}.  This first
@@ -112,7 +108,7 @@
 \subsection{Mixmaster}
 
 Mixmaster\footnote{Mixmaster version 3.0, as well as Reliable, also
-  optionally support the older ``Cypherpunk'' remailer message
+  optionally supports the older ``Cypherpunk'' remailer message
   format. For the purposes of this paper, we are assuming that the
   remailers are being operated without this support. As anonymity sets
   for the two protocols generally do not overlap, this does not impact
@@ -156,8 +152,8 @@
 
 \subsection{Reliable}
 
-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
+Reliable is loosely based on the Stop-and-Go (\emph{S-G Mix}) mix proposed
+by Kesdogan \emph{et al.} in~\cite{stop-and-go}. In S-G 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
@@ -166,19 +162,17 @@
 
 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.
-
-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.
+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). Reliable cannot
+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
+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
@@ -192,14 +186,14 @@
 \subsection{Dummy traffic}
 \label{dummy}
 
-A dummy message is a \emph{fake} message introduced in 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 message is
-normally produced by the mixes, and they select as destination another
-mix instead of a real recipient.
+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.
 
 Dummies are indistinguishable from real messages as they travel in the
-mix network. As they are introduced to prevent traffic analysis, the
+mix network. Since they are introduced to prevent traffic analysis, the
 dummy policy should maximize the number of possible destinations for
 the messages flushed by the mix. Dummy traffic has an impact when
 analyzing the mix network as a whole. We have made measurements that
@@ -211,12 +205,11 @@
 \paragraph{Dummy policy of Mixmaster}
 Every time a message is received by Mixmaster, an algorithm runs to
 generate $d_1$ dummies that are inserted in the pool of the mix. The
-number $d_1$ of dummies generated follow a geometrical distribution
-whose parameter has the default value of $1/10$. Moreover, every time
-Mixmaster flushes messages, it generates a number $d_2$ of dummies
-that are sent along with the messages. The number $d_2$ of dummies
-follows a geometrical distribution whose parameter has the default
-value $1/30$. 
+number $d_1$ of dummies generated follow a geometrical distribution whose
+parameter has the default value of $1/10$. In addition, every time
+Mixmaster flushes messages, it generates a number $d_2$ of dummies that
+are sent along with the messages. The number $d_2$ of dummies follows a
+geometrical distribution whose parameter has the default value $1/30$.
 
 
 \paragraph{Dummy policy of Reliable}
@@ -262,7 +255,7 @@
 \\
 
 Note that in these two cases, the metric computes the anonymity of a
-\emph{particular} input or output message, it does not give a general
+\emph{particular} input or output message; it does not give a general
 value for a mix design and it is dependent on the traffic pattern. The
 advantage of this property is that mixes may offer information about the
 \emph{current} anonymity they are providing. The disadvantage is that it
@@ -342,7 +335,7 @@
 
 \subsection{Analysis of the input traffic}
 
-It is a common assumption in the literature that the arrivals to a mix
+It is a common assumption in the literature that the arrivals at a mix
 node follow a Poisson process. We have analyzed the input traffic, and
 found that it does not follow a Poisson distribution nor can it be modeled 
 with one time-independent parameter. 
@@ -357,28 +350,30 @@
 is \emph{time-independent}.
 
 In our statistical analysis we first \emph{assumed} that the process of arrivals
-\emph{was} a Poisson process and we estimated the parameter $\lambda$. The latter
-was done by taking the maximum likelihood estimate given the number 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
+
+\emph{was} a Poisson process and we estimated the parameter $\lambda$. The
+latter was done by taking the maximum likelihood estimate given the number
+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
 performed a goodness-of-fit test: can we reject the hypothesis
 \begin{equation*}
 H_0: \mathrm{the\ number\ of\ arrivals\ per\ time\ interval\ } \sim\ \mathrm{Poiss}(\bar\lambda)\ ,
 \end{equation*}
 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$)!
+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$)! 
 % END (Evelyne)
 
-In the left part of Figure~\ref{arr-day} we show the number of messages arrived to
-the mix per hour. The right part of Figure~\ref{arr-day} shows
+In the left part of Figure~\ref{arr-day} we show the number of messages
+received by the mix per hour. The right part of Figure~\ref{arr-day} shows
 the evolution of the arrivals per day. We can observe that the traffic
 arrived to the mix during the first month is much heavier than in the
 following three months. This shows that the input traffic pattern that
-gets to a mix node is highly unpredictable and that the assumption of lambda being
-time-independent cannot be hold.
+gets to a mix node is highly unpredictable and that the assumption of
+lambda being time-independent cannot be hold.
 
 Figure~\ref{frec-day} shows the frequency in hours and in days of receiving a
 certain number of arrivals. We can see that in most of the hours 
@@ -507,12 +502,12 @@
 The theoretical method proposed in~\cite{stop-and-go} that gives a 
 probabilistic prediction on the anonymity provided by Reliable is 
 based on the assumption of Poisson traffic. As we have seen, this assumption
-is definitely not correct for mix traffic. 
+is definitely not correct for email mix traffic. 
 
 We have simulated a Reliable mix as explained in
 Section~\ref{sims}. 
-Reliable treats every message independently: when it gets a message
-it delays it a predetermined amount of time (picked from an exponential
+Reliable treats every message independently: when it receives a message
+it delays it for a predetermined amount of time (selected 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
@@ -561,13 +556,13 @@
 anonymity of around $7$, equivalent to perfect indistinguishability
 among $2^7=128$ input (output) messages. When the traffic load
 decreases, Mixmaster provides a larger latency in order to keep the
-anonymity in high levels. 
+anonymity at high levels. 
 
 Reliable delays messages according to an exponential distribution,
 regardless of the traffic load. This has an effect in the anonymity,
-that will only have high values when there is a high traffic
+in that it will only have high values when there is a high traffic
 load. When the traffic load decreases, the anonymity provided by
-Reliable goes down to very low values. In some cases of very low load,
+Reliable drops to very low values. In some cases of very low load,
 Reliable does not provide anonymity at all.
 
 Our conclusion is that a continuous mix like Reliable is not
@@ -595,7 +590,7 @@
 
 This paper does not aim to be an in-depth analysis of the full spectrum of
 host-attacks against remailer nodes. Nevertheless, it is important to
-mention some significant differences between Reliable and Mixmaster which
+mention some significant differences between Reliable and Mixmaster that
 may affect their ability to provide adequate anonymity for their users.
 
 \subsection{Host server integrity}
@@ -605,7 +600,7 @@
 security. Some considerations include shared access to the system by
 untrusted users, access to key material on disk or in memory, and the
 ability to insert shims to attack dynamically loaded libraries called by
-the remailer software.
+the remailer software~\cite{slimjim}.
 
 % Shared access by untrusted users
 % Access to key material, ability to link input and output
@@ -637,13 +632,13 @@
 order to ensure that the software is used consistently and
 correctly~\cite{sassaman-lisa}. A greater level of skill can safely be
 assumed when designing privacy software which is intended to be operated
-as a service, however. Most anonymity systems, including mix-net
+as a service, however. Most anonymity systems, including mix
 implementations, do imply a significant degree of complexity. Due to the
 fact that the operation of a public Internet service involves the correct
 configuration and maintenance of the host server, this necessary
 complexity is acceptable as long as the operator's skill level is
 sufficient. The level of skill required to properly install, configure,
-and operate a mix-net node should not exceed that required to properly
+and operate a mix node should not exceed that required to properly
 install, configure, and operate the server itself.
 
 The software packages we evaluated differed with regard to their interface
@@ -696,19 +691,19 @@
 
 In order to facilitate source code review and verification of an
 application's correctness with regard to its implementation of a protocol,
-it is beneficial for both good commenting in the source code and a clear
-specification for its behavior to exist. 
+it is beneficial for there to be both good commenting in the source code
+and a clear specification for its behavior.
 
 While neither program is sufficiently commented or written clearly enough
-to allow a reviewer to easily learn how either system works, there exists
-a complete specification of the Mixmaster node
-behavior~\cite{mixmaster-spec}. No such specification or description
+to allow a reviewer to easily learn how either system works by reading the
+source code alone, there exists a complete specification of the Mixmaster
+node behavior~\cite{mixmaster-spec}. No such specification or description
 exists for Reliable.
 
 \subsection{Included libraries} 
 
 In addition to the standard POSIX libraries provided by the compilation
-OS, Mixmaster 3.0, the version of Mixmaster evaluated in this paper,
+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} and ncurses~\cite{ncurses}.
@@ -716,7 +711,7 @@
 Reliable requires many native Windows system calls as well as the
 third-party application, Mixmaster 2.0.4.\footnote{Mixmaster 2.0.x is
 derived from an entirely different codebase than that of Mixmaster 3.0.
-While Reliable relies on Mixmaster 2.0.4 binary for some of its
+While Reliable relies on the Mixmaster 2.0.4 binary for some of its
 functionality, Reliable is a substantive application in its own right, and
 should not be considered a mere extension to the Mixmaster codebase.}
 
@@ -736,11 +731,11 @@
 Reliable abstracts the cryptographic operations one step further. To
 support the Mixmaster message format, Reliable acts as a wrapper around
 the DOS version of Mixmaster 2.0.4. Thus, any attack against the Mixmaster
-message format due to implementation flaws in Mixmaster 2.0 will work
+message format due to implementation flaws in Mixmaster 2.0.x will work
 against Reliable as well. Mixmaster 2.0.4 relies on the cryptographic
 library OpenSSL or its predecessor SSLeay for the MD5, EDE-3DES, and RSA
 routines.\footnote {Prior to the expiration of the RSA patent, versions of
-Mixmaster 2.0 offered support for the RSAREF and BSAFE libraries as well.
+Mixmaster 2.0.x offered support for the RSAREF and BSAFE libraries as well.
 Use of these versions of Mixmaster is largely abandoned.}
 
 \subsection{Entropy sources}
@@ -756,7 +751,7 @@
 
 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 which employ the use of noisy diodes, or
+most systems\footnote{Systems which 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
@@ -764,16 +759,16 @@
 % \footnote{explanation of /dev/random , /dev/urandom , and Windows
 % entropy.}
 
-Mixmaster uses OpenSSL's rand\_ functions\footnote{OpenSSL relies on its
+Mixmaster uses OpenSSL's rand\_ functions.\footnote{OpenSSL relies on its
 internal PRNG seeded with various system sources to provide
-cryptographically strong entropy.}. Reliable uses the standard Windows
+cryptographically strong entropy.} Reliable uses the standard Windows
 system call, Rnd(), when obtaining entropy, with the exception of message
 and header padding (which is done by the supporting Mixmaster 2.0.4
 binary). The Rnd() function is not a cryptographically strong source of
-entropy. Rnd() starts with a seed value and generates numbers which fall
+entropy~\cite{MSKBVB-Rnd}. Rnd() starts with a seed value and generates numbers which fall
 within a finite range. Previous work has demonstrated that systems which
 use a known seed to a deterministic PRNG are trivially
-attackable~\cite{daw-ian-netscape,MSKBVB-Rnd}. While its use of Rnd() to
+attackable~\cite{daw-ian-netscape}. While its use of Rnd() to
 determine the latency for a message injected into the mix is the most
 devastating, Reliable uses Rnd() for many other critical purposes as well.
 
@@ -1002,7 +997,7 @@
 
 \bibitem[Cor]{MSKBVB-Rnd}
 Microsoft Corporation.
-\newblock Visual basic language reference--rnd function.
+\newblock Visual basic language reference--{R}nd function.
 \newblock {\em {MSDN Library}}.
 
 
@@ -1044,7 +1039,7 @@
 \bibitem[SDS]{sds}
 Andrei Serjantov, Roger Dingledine and Paul Syverson.
 \newblock From a trickle to a flood: Active attacks in several mix types.
-\newblock In {\em n the Proceedings of Information Hiding Workshop (IH
+\newblock In {\em Proceedings of Information Hiding Workshop (IH
   2002)}, LNCS 2578. October 2002.
 
 \bibitem[DS03b]{DS03}
@@ -1111,6 +1106,11 @@
   Privacy Enhancing Technologies Workshop (PET 2002)}. Springer-Verlag, LNCS
   2482, April 2002.
 
+\bibitem[Tha03]{slimjim}
+Rodney Thayer.
+\newblock Slim{J}im: shared library shimming for password harvesting.
+\newblock Presentation, {T}oor{C}on 2003, September 2003.
+
 \bibitem[Tho84]{trusting-trust}
 K.~Thompson.
 \newblock Reflections on trusting trust.

***********************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe freehaven-cvs       in the body. http://freehaven.net/
Next by Author: [freehaven-cvs]
Next by thread: [freehaven-cvs]
Index(es):
- Author
- Thread