[freehaven-cvs] in which I fix many grammar issues in order to more ...

[rabbi@seul.org]

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/