[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[freehaven-cvs] in which I fix many grammar issues in order to more ...
Update of /home2/freehaven/cvsroot/doc/mixmaster-vs-reliable
In directory moria.mit.edu:/tmp/cvs-serv24138
Modified Files:
mixvreliable.tex
Log Message:
... in which I fix many grammar issues in order to more clearly and
eloquently express myself in a manner which does not utilize the work
"which" when I should instead be using "that."
Index: mixvreliable.tex
===================================================================
RCS file: /home2/freehaven/cvsroot/doc/mixmaster-vs-reliable/mixvreliable.tex,v
retrieving revision 1.36
retrieving revision 1.37
diff -u -d -r1.36 -r1.37
--- mixvreliable.tex 1 Jul 2004 09:57:48 -0000 1.36
+++ mixvreliable.tex 1 Jul 2004 10:17:20 -0000 1.37
@@ -36,7 +36,7 @@
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
+its ability to provide anonymity, and review key areas that 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
@@ -118,7 +118,7 @@
collect messages for some time, place them in the pool (memory of the
mix), and select some of them for flushing in random order when the
flushing condition is fulfilled.
-Mixmaster is a timed mix which has a \emph{timeout} of 15
+Mixmaster is a timed mix that has a \emph{timeout} of 15
minutes. During this period of time, it collects messages that are
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
@@ -230,7 +230,7 @@
\label{metrics}
In this section we introduce the anonymity metrics for mixes and we
-present the attack model which we have considered. Let us first define
+present the attack model that we have considered. Let us first define
anonymity in this context. \emph{Anonymity} was defined by Pfitzmann
and K\"ohntopp~\cite{Pfitzmann00} as \emph{``the state of being not
identifiable within a set of subjects, the anonymity set''}.
@@ -374,7 +374,7 @@
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
+that arrived at 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 hold.
@@ -421,12 +421,11 @@
\subsection{Analysis of Mixmaster}
-We have simulated a Mixmaster node as explained in
-Section~\ref{sims}. Mixmaster is a pool mix and processes messages in
-batches. The recipient anonymity of all inputs of a round is the
-same. Equivalently, all outputs of a round have the same sender
-anonymity value. In this section we show the results obtained in our
-simulation.
+We have simulated a Mixmaster node as explained in Section~\ref{sims}.
+Mixmaster is a pool mix and processes messages in batches. The recipient
+anonymity of each message in a given round is the same. Equivalently, all
+outputs of a round have the same sender anonymity value. In this section
+we show the results obtained in our simulation.
In Figure~\ref{3d-sen} we show the correlation between the recipient anonymity
and the delay for every message. Figure~\ref{3d-sen} shows the
@@ -435,7 +434,7 @@
The first conclusion we come to when observing the figures is that
there is a lower bound to the anonymity of Mixmaster. It is worth
noting that, so far, we do not know any theoretical analysis of pool
-mixes able to predict the anonymity it provides, and prior to this
+mixes able to predict the anonymity a pool mix provides, and prior to this
analysis there were no figures on the anonymity that Mixmaster was
actually providing. With this simulation,
we can clearly see that Mixmaster guarantees a minimum sender and
@@ -563,7 +562,7 @@
anonymity at high levels.
Reliable delays messages according to an exponential distribution,
-regardless of the traffic load. This has an effect in the anonymity,
+regardless of the traffic load. This has an effect on the anonymity,
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 drops to very low values. In some cases of very low load,
@@ -579,7 +578,7 @@
browsing). Nevertheless, in order to provide acceptable levels of
anonymity, the traffic load should be kept high.
-\section{Other factors which influence anonymity}
+\section{Other factors that influence anonymity}
We have evaluated the anonymity strength of the mixing algorithms
implemented in Mixmaster and Reliable. Additional factors have a direct
@@ -635,7 +634,7 @@
In privacy application client, an intuitive user interface is essential in
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
+assumed when designing privacy software that is intended to be operated
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
@@ -680,7 +679,7 @@
programming language used to create that application. Mixmaster is written
in C, while Reliable is written in Visual Basic. Since neither Mixmaster
nor Reliable were written by seasoned software developers, we assume a
-level of experience which would allow for simplistic security
+level of experience that would allow for simplistic security
mistakes.\footnote{The bulk of the code for Mixmaster 3.0 was written by
Ulf M\"oller as his first major software development project while
completing his undergraduate computer science
@@ -724,9 +723,9 @@
Both Mixmaster and Reliable avoid direct implementation of cryptographic
algorithms when possible. Mixmaster 3.0 relies strictly on OpenSSL for
these cryptographic functions. Any attackable flaws in the cryptographic
-library used to build Mixmaster which affect the security if the
+library used to build Mixmaster that affect the security if the
algorithms\footnote{It is understood that flaws in the cryptographic
-algorithms will affect the security of software which relies upon those
+algorithms will affect the security of software that relies upon those
algorithms. However, since most attacks on cryptographic applications are
due to flaws in the implementation, care must be taken when evaluating the
shared cryptographic libraries.} used by Mixmaster may be a an attack
@@ -755,7 +754,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 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
@@ -769,7 +768,7 @@
binary). The Rnd() function is not a cryptographically strong source of
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
+that systems that use a known seed to a deterministic PRNG are trivially
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.
***********************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe freehaven-cvs in the body. http://freehaven.net/