[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[freehaven-cvs] Tighten further.

To: freehaven-cvs@freehaven.net
Subject: [freehaven-cvs] Tighten further.
From: rabbi@seul.org
Date: Thu, 1 Jul 2004 14:04:24 -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 14:04:35 -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-serv12938

Modified Files:
	mixvreliable.tex 
Log Message:
Tighten further.


Index: mixvreliable.tex
===================================================================
RCS file: /home2/freehaven/cvsroot/doc/mixmaster-vs-reliable/mixvreliable.tex,v
retrieving revision 1.49
retrieving revision 1.50
diff -u -d -r1.49 -r1.50
--- mixvreliable.tex	1 Jul 2004 17:11:43 -0000	1.49
+++ mixvreliable.tex	1 Jul 2004 18:04:22 -0000	1.50
@@ -300,7 +300,7 @@
 
 \section{Simulators} \label{sims} We have implemented Java simulators for
 Reliable and Mixmaster. We have fed the simulated mixes with real input,
-obtained by logging a timestamp every time a message arrived to a working
+obtained by logging a timestamp each time a message arrived to a working
 Mixmaster node (note that the information we logged does not threaten the
 anonymity of the users of the mix). We have used four months of incoming
 traffic (July-November 2003) to obtain the results presented in
@@ -470,18 +470,17 @@
 messages (data $> 41$).
 \end{description}
 
-In Figure~\ref{del-mm} we show the minutes of delay of every message
-(the x-axis indicates the evolution in time). 
-We can see that the delay only takes high values when the traffic 
-is low. The fact that some messages appear as having a delay close 
-to zero in the low traffic figure is due to the fact that we have more 
-samples, so there are messages that arrive just before the flushing and 
-are forwarded immediately. In Figure~\ref{an-mm} we show the recipient 
-anonymity of every message (the sender anonymity presents very similar
-characteristics). We can see that as the traffic increases, the anonymity 
-provided to the messages takes higher values. No matter how low the
-traffic load is, the anonymity provided by Mixmaster is always above $7$.
-
+In Figure~\ref{del-mm} we show the minutes of delay of every message (the
+x-axis indicates the evolution in time).  We can see that the delay only
+takes high values when the traffic is low. The fact that some messages
+appear as having a delay close to zero in the low traffic figure is due to
+the fact that we have more samples, so there are messages that arrive just
+before the flushing and are forwarded immediately. In Figure~\ref{an-mm}
+we show the recipient anonymity of every message (the sender anonymity
+presents very similar characteristics). We can see that as the traffic
+increases, the anonymity provided takes higher values. No matter how low
+the traffic load is, the anonymity provided by Mixmaster is always above
+$7$.
  
 \begin{figure}
 \begin{center}
@@ -524,11 +523,10 @@
 the messages can be trivially traced by a passive attacker. The
 maximum values of Reliable's anonymity for this input are lower  
 than Mixmaster's maximums.
-Figure~\ref{sen-rec} shows the correlation of sender and recipient
-anonymity for Reliable and Mixmaster. These values are highly
-correlated. We can clearly see that for Reliable some of the messages
-get nearly no anonymity, while the ones of Mixmaster get at least
-sender and recipient anonymity $7$. 
+Figure~\ref{sen-rec} shows the highly correlated values of sender and
+recipient anonymity for both Reliable and Mixmaster. We can clearly see
+that for Reliable some of the messages get nearly no anonymity, while the
+ones of Mixmaster get at least sender and recipient anonymity $7$.
 
 \begin{figure}
     \noindent
@@ -553,16 +551,14 @@
 
 As we have shown in the previous two sections, Mixmaster and Reliable
 have very different behaviors for the same traffic stream. Note that
-we have modified the default ($1$ hour) mean delay of Reliable in
-order to make a fair comparison between the two mixes (so the average
-delay of all messages is the same for the two mixes). 
+we have modified the default ($1$ hour) mean delay of Reliable, so that
+the average delay is the same as Mixmaster for comparison purposes.
 
 Mixmaster priorizes the anonymity over the delay, and it provides a
-minimum recipient (sender) 
-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 to keep the
-anonymity at high levels. 
+minimum recipient (sender) 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 to keep the
+anonymity at high levels.
 
 Reliable delays messages according to an exponential distribution,
 regardless of the traffic load. This has an effect on the anonymity,
@@ -608,12 +604,6 @@
 ability to insert shims to intercept dynamically loaded libraries called by
 the remailer software~\cite{slimjim}.
 
-% Shared access by untrusted users
-% Access to key material, ability to link input and output
-% Memory attacks
-% Disk attacks
-% Dynamically loaded library shims
-
 Reliable is limited to operation on the Windows platform. Mixmaster is
 portable, and has been known to run on a wide variety of operating
 systems.\footnote{There have been instances of remailers based on the
@@ -634,18 +624,17 @@
 % figure out Mixmaster probably can't satisfy the requirements in the above
 % section.
 
-In a privacy application client, an intuitive user interface is essential in
-order to ensure that the software is used consistently and
+In a 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 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
-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 node should not exceed that required to properly
-install, configure, and operate the server itself.
+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. Since 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 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
 complexity in a number of areas.
@@ -664,10 +653,7 @@
 operate than Mixmaster. However, Mixmaster's difficulty does not rise
 above the difficulty of maintaining a secure Internet-connected server,
 and thus has little effect on the overall security of a mix node
-deployment. Hobbyists unable to maintain Mixmaster are equally unlikely to
-be able to secure their host server.
-
-% Installation, configuration, operation, key rotation, MTA issues.
+deployment.
 
 \subsection{Programming language}
 
@@ -695,10 +681,10 @@
 
 \subsection{Source code documentation}
 
-To facilitate source code review and verification of an
-application's correctness with regard to its implementation of a protocol,
-it is beneficial for there to be both good commenting in the source code
-and a clear specification for its behavior.
+To facilitate source code review and verification of an application's
+correctness with regard to its implementation of a protocol, 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 by reading the

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