[freehaven-cvs] More clarity/grammar.

[rabbi@seul.org]

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

Modified Files:
	mixvreliable.tex 
Log Message:
More clarity/grammar.


Index: mixvreliable.tex
===================================================================
RCS file: /home2/freehaven/cvsroot/doc/mixmaster-vs-reliable/mixvreliable.tex,v
retrieving revision 1.42
retrieving revision 1.43
diff -u -d -r1.42 -r1.43
--- mixvreliable.tex	1 Jul 2004 10:35:55 -0000	1.42
+++ mixvreliable.tex	1 Jul 2004 10:59:29 -0000	1.43
@@ -595,7 +595,7 @@
 underlying host server. Many factors can impact the underlying system's
 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
+ability to insert shims to intercept dynamically loaded libraries called by
 the remailer software~\cite{slimjim}.
 
 % Shared access by untrusted users
@@ -705,23 +705,23 @@
 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.\footnote{Mixmaster 2.0.x is
-derived from an entirely different codebase than that of Mixmaster 3.0.
-While Reliable relies on the Mixmaster 2.0.4 binary for some of its
-functionality, Reliable is a independent application in its own right, and
-should not be considered a mere extension to the Mixmaster codebase.}
+third-party application, Mixmaster 2.0.4.\footnote{Mixmaster 2.0.x has an
+entirely different codebase than that of Mixmaster 3.0. While Reliable
+relies on the Mixmaster 2.0.4 binary for some of its functionality,
+Reliable is an independent application in its own right, and should not be
+considered a mere extension to the Mixmaster codebase.}
 
 \subsection{Cryptographic functions}
 
 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 that affect the security if the
+library used to build Mixmaster that affect the security of the
 algorithms\footnote{It is understood that flaws in the cryptographic
 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
+shared cryptographic libraries.} used by Mixmaster may be an attack
 against Mixmaster as well.
 
 Reliable abstracts the cryptographic operations one step further. To
@@ -739,7 +739,7 @@
 The quality of the entropy source plays an extremely important role in
 both the pool mix and S-G mix schemes. In pool mix systems, the mixing in
 the pool must be cryptographically random in order to mix the traffic in a
-non-deterministic way. The timestamps used to determine how long a message
+non-deterministic way. The timestamps that determine how long a message
 should be held by an S-G mix implementation must also be from a strong
 entropy source for the same reasons. In addition, the Mixmaster message
 format specifies the use of random data for its message and header
@@ -760,7 +760,7 @@
 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~\cite{MSKBVB-Rnd}. Rnd() starts with a seed value and generates 
-numbers which fall within a finite range. Previous work has demonstrated
+numbers which fall within a limited range. Previous work has demonstrated
 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,
@@ -770,8 +770,8 @@
 
 By analyzing the input and output traffic of a mix, a skilled attacker may
 be able to deduce the value of pool variables by timing observation. This
-affects pool-mixes more than S-G mixes, and possibly aids attacker in some
-non-host based active attacks such as $(n-1)$ attacks. The anonymity
+affects pool mixes more than S-G mixes, and possibly aids an attacker in
+some non-host based active attacks such as $(n-1)$ attacks. The anonymity
 strength of a remailer should not require pool values to be hidden, and
 countermeasures to this class of active attacks should be
 taken~\cite{rgb-mix}.
@@ -790,14 +790,14 @@
 We measure the anonymity of the pool mix scheme used in Mixmaster by
 applying a metric previously proposed in the literature. We provide our
 own metric for evaluating the anonymity of the S-G mix variant used in
-Reliable which does not assume a Poisson traffic pattern.
+Reliable that does not assume a Poisson traffic pattern.
 
 Our comparison of the two predominant mixing applications shows that
 Mixmaster provides superior anonymity, and is better suited for the
 anonymization of email messages than Reliable. Mixmaster provides a
 minimum level of anonymity at all times; Reliable does not. Reliable's
 anonymity drops to nearly zero if the traffic is very low. In high-traffic
-situations, Mixmaster provides a higher maximum of anonymity than Reliable
+situations, Mixmaster provides a higher maximum anonymity than Reliable
 for the same stream of input: $10.5$ of Mixmaster versus $10$ of Reliable.
 We have shown that Mixmaster provides higher average anonymity than
 Reliable for the same input and same average delay. Due to its nature as a
@@ -808,18 +808,18 @@
 In addition, we have identified a number of key points of attack and
 weakness in mix software to which anonymity software designers need to pay
 particular attention. In addition to the areas of theoretical weakness
-which we have identified, we discovered a fatal flaw in the use of
+that we have identified, we discovered a fatal flaw in the use of
 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 Reliable mixes are not suitable for use with systems
-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. Mixmaster should be used for systems with fluctuating
-traffic loads. 
+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
+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.
 
 %%% end input Len
 

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