[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[freehaven-cvs] reorganized paper structure
Update of /home2/freehaven/cvsroot/doc/pingers
In directory moria:/tmp/cvs-serv5572
Modified Files:
pingers.tex
Log Message:
reorganized paper structure
Index: pingers.tex
===================================================================
RCS file: /home2/freehaven/cvsroot/doc/pingers/pingers.tex,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -d -r1.11 -r1.12
--- pingers.tex 10 Mar 2006 20:52:32 -0000 1.11
+++ pingers.tex 10 Mar 2006 21:00:58 -0000 1.12
@@ -72,7 +72,7 @@
We present \emph{Echolot}, the most advanced remailer reliability
monitoring software and \emph{Leuchtfeuer}, a protocol enhancement for
-mix-networks which eliminates the active and passive intersection attacks
+mix-nets which eliminates the active and passive intersection attacks
that are possible when different users obtain conflicting reliability
statistics about the mix-net.
@@ -85,14 +85,14 @@
providing secure anonymous network communication. The publicly accessible
mix networks, such as the ``Type I'' Cypherpunk remailers, the ``Type II''
Mixmaster network, and the ``Type III'' Mixminion network~\cite{}, as well
-as the low-latency network anonymity service Tor are operated by
-volunteers and are prone to intermittent failure of individual nodes. It
-is therefore necessary for mix client software to have an accurate view of
-the health of the nodes in the mix network. This information is gathered
-by sending test messages through each node, and observing the success or
-failure of the mix to successfully transmit the message. In a similar
-fashion, links between mixes are examined by sending messages through
-every combination of two consecutive mixes. Since the overhead and
+as the low-latency network anonymity service Tor, are operated on a
+volunteer basis and are prone to intermittent failure of individual nodes.
+It is therefore necessary for mix client software to have an accurate view
+of the health of the nodes in the mix network. This information is
+gathered by sending test messages through each node and observing the
+success or failure of the mix to successfully transmit the message. In a
+similar fashion, links between mixes are examined by sending messages
+through every combination of two consecutive mixes. Since the overhead and
operational complexity involved in monitoring an entire network of mixes
is too great for the average user, reliability testing servers, or
\emph{pingers}, perform this function and publish their results in a
@@ -154,7 +154,62 @@
% FIXME: if rlist didn't do the 'secret token in ping', mention it here
-\subsection{Echolot}
+\subsection{Mixminion directory server}
+
+Mixminion~\cite{mixminion} generalized the concept of pingers, defining a
+directory server component of the Mixminion system, responsible for the
+distribution of all information about remailer availability, performance,
+and key material. The designers of the Mixminion system considered the
+attacks on the independent pinger model, and specified that directory
+servers be synchronized as well as redundant.
+
+%FIXME [Does Mixminion have any details on calculation stategy? Not sure,
+%but I should check the source.]
+%
+% Apparently, Mixminion doesn't do any actual pinging. Scratch that.
+%
+
+Mixminion publishes signed \emph{capability blocks} in the directory
+server, consisting of the supported mix protocol versions, mix's address,
+long-term (signing) public key, short-term (message decryption) public
+key, remixing capability, and batching strategy.
+
+
+\section{Veracity attacks}
+
+A mix which is otherwise honest (in that it correctly performs mixing
+duties without breaking the anonymity of the messages transmitted through
+it) may attempt to convince a pinger to provide false information
+regarding the performance of the mix, by identifying the source address of
+pings, and treating the pinger messages differently than normal messages.
+While this manipulation will not change basical results such as the
+operational status of a defunct mix, it could allow a mix to alter the
+latency statistics reported for its operation.
+%
+\label{section:gaming}
+We experimented in Echolot 1.x with a technique intended to discourage such
+cheating by creating ping messages which originate and terminate at a local mix
+which also mixes normal messages, so that the target mix cannot distinguish
+between user messages and pinger messages. Unfortunately, systems such as
+Mixmaster have a minimum distance between hops which is considered when
+creating a mix chain, and thus messages which consist of the mix chain
+A,B,A will still be distinguishable as pinger messages, since no properly
+functioning mix client would generate this chain. If a pinger were to
+create a chain of A,B,C,A, neither mixes B or C would be able to tell that
+the message contained pinger information, but the results would only
+indicate the combined latency of the mixes B and C, as well as the health
+of both B and C and the link between those mixes. It would not provide any
+useful information about B or C alone.
+
+The pinger message data (or \emph{pings}) itself should not be
+deterministic, lest a mix attempt to "back-fill" the results for pings
+sent during a period when the mix was offline.
+
+
+%%%% ECHOLOT SECTION
+
+
+\section{Echolot}
% FIXME: please add bibitems for echolot1 and echolot2:
% http://www.palfrader.org/echolot/download/echolot1/
@@ -175,7 +230,7 @@
networks. As of this writing,
there are nineteen Echolot pingers in operating publicly~\cite{allpingers}.
-\subsubsection{Reliability measurement aspects}
+\subsection{Reliability measurement aspects}
Echolot tests multiple areas of failure in the remailer networks and
collates this data in a format the Mixmaster software can process,
@@ -203,7 +258,7 @@
pairing of nodes in a chain.
% XXX: nothing reports or cares about latencies of chain pings -- weasel
-\subsubsection{Node discovery}
+\subsection{Node discovery}
Distributed mix-nets consisting of independent operators often do not
allow for a guaranteed means for nodes to communicate join and exit events
@@ -230,7 +285,7 @@
%
% - weasel
-\subsubsection{Echolot algorithm}
+\subsection{Echolot algorithm}
Echolot's approach for determining remailer reliability is simple.
Distributed over the course of a day Echolot sends several pings through
@@ -316,58 +371,9 @@
chain is now broken. Fortunately experience with the currently deployed
Mixmaster network shows that broken chains do not change very often.
-
-\subsection{Mixminion directory server}
-
-Mixminion~\cite{mixminion} generalized the concept of pingers, defining a
-directory server component of the Mixminion system, responsible for the
-distribution of all information about remailer availability, performance,
-and key material. The designers of the Mixminion system considered the
-attacks on the independent pinger model, and specified that directory
-servers be synchronized as well as redundant.
-
-%FIXME [Does Mixminion have any details on calculation stategy? Not sure,
-%but I should check the source.]
-%
-% Apparently, Mixminion doesn't do any actual pinging. Scratch that.
-%
-
-Mixminion publishes signed \emph{capability blocks} in the directory
-server, consisting of the supported mix protocol versions, mix's address,
-long-term (signing) public key, short-term (message decryption) public
-key, remixing capability, and batching strategy.
-
+%%%% END ECHOLOT
-\section{Gaming the data}
-
-A mix which is otherwise honest (in that it correctly performs mixing
-duties without breaking the anonymity of the messages transmitted through
-it) may attempt to convince a pinger to provide false information
-regarding the performance of the mix, by identifying the source address of
-pings, and treating the pinger messages differently than normal messages.
-While this manipulation will not change basical results such as the
-operational status of a defunct mix, it could allow a mix to alter the
-latency statistics reported for its operation.
-%
-\label{section:gaming}
-We experimented in Echolot 1.x with a technique intended to discourage such
-cheating by creating ping messages which originate and terminate at a local mix
-which also mixes normal messages, so that the target mix cannot distinguish
-between user messages and pinger messages. Unfortunately, systems such as
-Mixmaster have a minimum distance between hops which is considered when
-creating a mix chain, and thus messages which consist of the mix chain
-A,B,A will still be distinguishable as pinger messages, since no properly
-functioning mix client would generate this chain. If a pinger were to
-create a chain of A,B,C,A, neither mixes B or C would be able to tell that
-the message contained pinger information, but the results would only
-indicate the combined latency of the mixes B and C, as well as the health
-of both B and C and the link between those mixes. It would not provide any
-useful information about B or C alone.
-
-The pinger message data (or \emph{pings}) itself should not be
-deterministic, lest a mix attempt to "back-fill" the results for pings
-sent during a period when the mix was offline.
%EXPAND AND CLEAN UP THE ABOVE
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxx with
unsubscribe freehaven-cvs in the body. http://freehaven.net/