[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[freehaven-cvs] r1755: Recommit the latest CVS changes. (doc/trunk/pingers)
Author: rabbi
Date: 2006-12-06 22:06:46 -0500 (Wed, 06 Dec 2006)
New Revision: 1755
Modified:
doc/trunk/pingers/echolot.bib
doc/trunk/pingers/echolot.tex
Log:
Recommit the latest CVS changes.
Modified: doc/trunk/pingers/echolot.bib
===================================================================
--- doc/trunk/pingers/echolot.bib 2004-11-28 16:17:51 UTC (rev 1754)
+++ doc/trunk/pingers/echolot.bib 2006-12-07 03:06:46 UTC (rev 1755)
@@ -14329,20 +14329,16 @@
}
@inproceedings{CachinKLS02,
- author = {Christian Cachin and
- Klaus Kursawe and
- Anna Lysyanskaya and
- Reto Strobl},
- title = {Asynchronous verifiable secret sharing and proactive cryptosystems.},
- booktitle = {ACM Conference on Computer and Communications Security},
- year = {2002},
- pages = {88-97},
- ee = {http://doi.acm.org/10.1145/586110.586124},
- crossref = {DBLP:conf/ccs/2002},
- bibsource = {DBLP, http://dblp.uni-trier.de}
+ author = {Christian Cachin and Klaus Kursawe and Anna Lysyanskaya and Reto Strobl},
+ title = {Asynchronous verifiable secret sharing and proactive cryptosystems.},
+ booktitle = {ACM Conference on Computer and Communications Security},
+ year = {2002},
+ pages = {88-97},
+ ee = {http://doi.acm.org/10.1145/586110.586124},
+ bibsource = {DBLP, http://dblp.uni-trier.de}
}
+% crossref = {DBLP:conf/ccs/2002},
-
@misc{MAFTIA,
link = "http://www.maftia.org";
}
@@ -14924,10 +14920,12 @@
}
@misc{echolot,
- author = {Redacted},
+ author = {Peter Palfrader},
title = {Echolot: a pinger for anonymous remailers},
year = {2001-},
+ note = {\url{http://www.palfrader.org/echolot/}},
}
+
@misc{rlist,
title = {{rlist}},
author = {Raph Levien},
Modified: doc/trunk/pingers/echolot.tex
===================================================================
--- doc/trunk/pingers/echolot.tex 2004-11-28 16:17:51 UTC (rev 1754)
+++ doc/trunk/pingers/echolot.tex 2006-12-07 03:06:46 UTC (rev 1755)
@@ -33,22 +33,21 @@
\setlength{\rightmargin}{0in}} \small \item}{\end{list}}
-\title{Echolot}
+\title{Echolot and Leuchtfeuer}
\subtitle{Measuring the Reliability of Unreliable Mixes}
% Blinded for submission
+\author {Klaus Kursawe\inst{1} and Peter Palfrader\inst{2} and Len Sassaman\inst{1}}
-\author {Peter Palfrader\inst{1} and Len Sassaman\inst{2}}
-
%foo
-\institute{Paris Lodron Universit\"at Salzburg\\
+\institute{Katholieke Universiteit Leuven\\
+Kasteelpark Arenberg 10, B-3001 Leuven-Heverlee, Belgium\\
+\email{\{len.sassaman,klaus.kursawe\}@esat.kuleuven.be}
+\and
+Paris Lodron Universit\"at Salzburg\\
Salzburg, Austria\\
\email{ppalfrad@xxxxxxxxxxxxxx}
-\and
-Katholieke Universiteit Leuven\\
-Kasteelpark Arenberg 10, B-3001 Leuven-Heverlee, Belgium\\
-\email{len.sassaman@xxxxxxxxxxxxxxxx}
}
%foo
@@ -66,14 +65,20 @@
applications so they may select reliable nodes to use in each message's
path through the mix-net. We introduce the concept of a \emph{pinger}, an
agent which tests the reliability of individual mixes in the mix-net, and
-publishes its results for the mix clients.
+publishes results for the mix clients to evaluate.
-We evaluate the security concerns regarding an pingers, including the
+We discuss the security concerns regarding pingers, including the
issues regarding anonymity set preservation, information disclosure, and
node cheating. We present our software \emph{Echolot}, the most
comprehensive and widely adopted pinger for the Mixmaster anonymous
remailer network.
+To address a serious anonymity weakness potentially introduced by the
+careless deployment of pingers, we present \emph{Leuchtfeuer}, a new
+protocol enhancement for mix-nets. Leuchtfeuer eliminates the active and
+passive intersection attacks that are possible when different users obtain
+conflicting reliability statistics about the mix-net.
+
\end{abstract}
@@ -104,9 +109,14 @@
have been developed for the Mixmaster network, and describe the problems
they attempt to address, as well as their relative success at doing so. We
present Echolot, our pinger implementation which more adequately addresses
-the problem of reliability monitoring than the other pingers.
+the problem of reliability monitoring than the other pingers. Finally, we
+explain the problem of pinger inconsistency, an issue which poses
+significant security implications and is shared by all existing pingers
+and mix clients. To solve this, we present the pinger agreement protocol
+Leuchtfeuer.
+
\section{Related work}
\label{pingers}
@@ -117,7 +127,7 @@
Cypherpunk remailer network; support for the Mixmaster network was added later.
Once started, rlist would run indefinitely, regularly sending simple test
-messages through remailers and building statistic files.
+messages through remailers and building statistics files.
% I haven't the slightest clue how rlist comes up with its reliability number.
% it's certainly black magic. -- weasel
@@ -133,7 +143,7 @@
% so a remailer can't just make up pings if me missed a few
Pingstats~\cite{pingstats}, developed between 2000 and 2003 by a programmer
-using the pseudonym of cmeclax, is a pinger both Cypherpunk and Mixmaster
+using the pseudonym of cmeclax, is a pinger for both Cypherpunk and Mixmaster
remailers. It consists of a C program which computes the statistics and a
collection of shell scripts that manage the creation, sending, and
receiving aspect of pinging, as well as help with collecting keys of known
@@ -144,7 +154,7 @@
Pingstats employs random tokens in message payloads as a counter-measure
to cheating mixes (see section \ref{section:gaming} below).
-Pingstats presents a more timely view of the state of the network, by
+Pingstats presents a more timely view of the state of the network by
using weighted pings for its reliability calculation. Thus, older ping
results are given less weight than more recent data.
@@ -168,7 +178,25 @@
% Is it documented anywhere? I suppose you're right. While not useful as
% a remailer, it isn't a terrible pinger. -- rabbi
+\subsection{Mixminion directory server}
+Mixminion\cite{mixminion} generalized the concept of pingers, defining a
+directory server component of the Mixminion system which is 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}
\label{section:gaming}
@@ -196,7 +224,7 @@
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
+deterministic, lest a mix attempt to ``back-fill'' the results for pings
sent during a period when the mix was offline. This can be prevented by
the inclusion of random tokens in the message payload of the ping, so that
pings returned to a pinger without bearing the token of an outstanding
@@ -208,7 +236,7 @@
\section{Echolot}
-The first version Echolot~\cite{echolot} was written in 2001. It sent pings
+The first version of Echolot~\cite{echolot} was written in 2001. It sent pings
through a local Mixmaster node in order to prevent the nodes being tested
from learning that a message contained a ping. Other than that it was fairly
similar to other pinger software in existence at the time.
@@ -217,8 +245,8 @@
being a group of programs with order-of-execution dependencies and
potential race conditions as its predecessor (and all other existing pingers) were, Echolot 2.x was built as
a single daemon. In addition to the normal single hop pings, this version
-also featured automated node discovery. The following year with Echolot
-2.1 chain pinging was added.
+also featured automated node discovery. The following year Echolot
+2.1 was released, adding the capability for chain pinging.
Echolot is the most widely used pinger for the Types 1 and 2 remailer networks.
As of this writing, there are over a dozen Echolot pingers operating
@@ -229,7 +257,7 @@
Echolot tests multiple areas of failure in the remailer networks and
collates this data in a format the Mixmaster software can process,
allowing the mix clients to make as much use of the available network
-resources as possible, without preventable packet loss.
+resources as possible without preventable packet loss.
The most basic test of reliability is the ``single ping'' test, wherein
the known nodes of the mix-net are each periodically sent individual
@@ -239,7 +267,7 @@
being tested.
When performing a ``chain ping'' test, Echolot creates a message of path
-length equal to two, for all combinations of any two remailers in the
+length equal to two for all combinations of any two remailers in the
network, and tests each of these pairings. If both remailers consistently
return single pings, but fail to return chained pings, one can deduce that
the failure is occurring at the link between the two nodes. Thus, either
@@ -321,7 +349,7 @@
The weight $w_i$ of a ping is made up of two factors: $w1_i \cdot w2_i$.
The first of them, $w1_i$ is strictly a function of the ping's age:
-Pings younger than 24 hours have a weight of $0.5$, for older pings
+Pings younger than 24 hours have a weight of $0.5$; after 24 hours
$w1$ is $1.0$ for a while until the weight decreases to zero for pings
older than 12 days. See table \ref{table:pingweight1} for the exact
numbers used in the Echolot software.
@@ -348,14 +376,14 @@
To illustrate this, assume a ping was sent two hours ago, which
makes $age_{skewed}$ 84 minutes. If all pings returned from
-this node were faster than 84 minutes then $w2$ is $1.0$. If only
-a third of pings were received within that time frame then $w2$ is
+this node were faster than 84 minutes, then $w2$ is $1.0$. If only
+a third of pings were received within that time frame, then $w2$ is
$0.33$. If no ping was ever faster than 84 minutes, then $w2$ is
zero.
This weighting based on past behavior was introduced to accurately
-report reliability of remailers that have vastly different latencies.
-There exist Mixmaster nodes which return pings within minutes of sending
+report the reliability of remailers that have vastly different latencies.
+There exist Mixmaster nodes which return pings within minutes of sending,
while others often take many hours to forward a message~\cite{latencies}.
In addition to reliability, Echolot also reports a node's latency. The
@@ -384,17 +412,325 @@
Chains are considered interesting by Echolot when
\begin{itemize}
-\item less than 3 pings have been sent without any returning, or
+\item fewer than 3 pings have been sent without any returning, or
\item the chain is currently reported broken.
\end{itemize}
Because Echolot pings chains that it considers working only once a
week, it may take a while before it realizes that a previously working
chain is now broken. Fortunately, experience with the currently deployed
-Mixmaster network shows that broken chains do not change very often.
+Mixmaster network shows that broken chains do not change very often.~\cite{FIXME} {\em FIXME, Peter!}
%%%% END ECHOLOT
+\section{Anonymity set attacks based on pinger data}
+
+A mix network in which users obtain their view of the network's heath and
+status from multiple independent sources opens the system to partitioning
+attacks~\cite{trickle02} against the users, based on differences in the mix
+selection based on the results of the different pingers. In a system of
+entirely honest pingers, this attack is feasible for an adversary
+operating in the passive observer model.
+
+Suppose Alice retrieved her network health information from pinger 1, and
+Bob retrieved his information from pinger 2. An observer watching the
+network local to Alice or Bob would know which pinger the user under
+observation chose. If the information provided by both pingers differed in
+some manner, the delta would contain mixes that, if chosen by Alice or
+Bob, would betray which pinger had been used to obtain this information. A
+message processed by a mix contained only in the results provided by
+pinger 1 could not have been sent by Bob, who obtains his results from a
+pinger lacking that information.
+
+Additionally, differences in pinger results for mix latency could lead to
+more subtle variations in mix path selection, which may aid an attacker.
+
+If a pinger is operated by an attacker, it becomes possible to
+specifically target individual users by providing them with unique
+information about the network in order to partition them into an
+anonymity set of size 1. Users can attempt to prevent against this attack
+by obtaining their pinger results from a widely-published location, such
+as Usenet, though this does not completely solve the partitioning attack
+problem, and introduces additional reliability constraints on the quality
+of the pinger information.
+
+Additionally, many users retrieve from the pinger updated keys for the remailers at the same as time they update their stats. The pinger\footnote{or an attacker performing a man-in-the-middle attack on the data retrieval session.} could manipulate the user into using keys other than those the user intended to. An attacker who controlled both the pinger used by his target and a number of mixes in the network could observe the target's messages moving through his mixes by performing a key-swapping attack with the pinger. By providing the target with a public key other than the one generally available for the mixes he controls, the target's messages would be easily distinguishable when processed by his mixes.
+
+
+% More attacks? FIXME
+% - most users also fetch keys with the stats
+% -> an attacker could not just give Alice a different list of nodes, but
+% could give her the same list only with a different key for his
+% remailers, so he can easily distinguish her messages when he seems them
+% at his node
+
+\section{Creating a consensus directory}
+
+The solution to the partitioning attacks mentioned in the previous section
+involves providing all clients with the same view of the network. Each
+pinger should calculate its results for the status of the network and
+compare these results with those of the other pingers. The pingers then
+must agree on a compromise result which reflects an accurate view of mix
+availability and provides every client with a consistent information with
+which to calculate message paths.
+
+
+Since the infamous FLP impossibility proof~\cite{filypa85}, it is known
+that a simple problem such as reaching consensus in the presence of faulty
+parties -- even if the worst they can do is to crash -- is rather hard,
+and a significant amount of research has been put into securing distributed
+systems against faulty parties~\cite{schnei90,deblfa91}. In the
+mix-net scenario, the main parties for the agreement protocols are the {\em
+pingers}, i.e., the parties that maintain a database on the active mixes,
+their authentication keys and some of their properties. They need to
+agree on a consistent status of the {\em mixes} and then deliver it on
+request to the {\em clients}. As the clients should not be forced to
+contact more pingers than needed, each honest mix should be able to prove
+that the result it forwards to the client is in fact the genuine outcome
+of the agreement.
+
+Depending on the attack model, the solutions can be rather complex, and in
+many implementations weaker attack models are chosen to allow for simpler
+protocols. In the Mixminion protocol, for example, the agreement protocol
+can easily be circumvented by one (or several) parties stopping the
+communication after a while -- a condition that may be constructed even if
+none of the involved pingers is actually corrupt. The honest parties may
+recognize they are in a bad condition and alert the administrator, but it is
+left to human interference to actually recreate consensus; as the
+disagreement may be created without any party behaving obviously
+dishonestly, this may place quite some burden on the administration.
+
+The protocol suite presented here will guarantee a consensus independent of
+timing assumptions, as long as fewer than a third of all pingers behave in an
+actively malicious fashion. For additional security, one can still add tests along
+the lines of the Mixminion protocol to detect inconsistencies and alert
+the administrators; however, if more than a third of the pingers are
+actively corrupt, the system is in a sufficiently bad state that its
+survival is questionable.
+
+\subsection{The Tools}
+
+In this section, we introduce the basic building blocks needed for our
+protocol. Due to lack of space, we do not give a formal model here. The
+protocols we choose were mostly developed within the MAFTIA
+project~\cite{maftiad26}; using new randomization techniques, these protocols
+are the first practical protocols that can deal with the maximum possible
+number of corruptions, and do not require any timing assumptions.
+
+\subsubsection{Binary Byzantine Agreement.}
+
+The basic protocol behind our consensus protocols is a binary Byzantine
+agreement protocol~\cite{lashpe82,cakush00}, which allows parties to
+agree on a simple binary value. In addition to agreement, the output
+value also must depend on the input values; in our case, this means it
+must be proposed by at least one non-corrupted pinger. We also want to
+obtain a proof of the outcome, so one single pinger can prove to an
+external party what the outcome of a particular protocol instance was.
+
+
+\subsubsection{Verifiable Multivalued Byzantine Agreement.}
+
+A multivalued Byzantine agreement protocol~\cite{ckps01} allows the pingers
+to agree on any bit-string, rather than only a binary value. As there is a
+(potentially) infinite universe of possible values, a multivalued
+Byzantine agreement protocol can no longer guarantee that the output of
+the protocol is the input of some honest party -- this would only be
+possible if all honest parties propose the same value. It is, however,
+possible to enforce that all honest parties verify the value prior to
+agreement, and thus guarantee that it satisfies some properties, e.g.,
+that it has the expected format, or contains proper signatures that
+certify its validity.
+
+\subsubsection{Broadcast protocols.}
+
+Broadcast protocols~\cite{ckps01} are used to send messages from one
+sender to a number of receivers. In the simplest version, the sender
+simply sends the message to every other party (Note that in the Mixminion
+protocol, the receivers poll the messages, rather than the sender pushing
+them; for our purpose, this does not pose a significant difference). This
+simple protocol does not give any guarantees to the receivers, however;
+some may receive different messages, or no message at all.
+
+A {\em consistent broadcast}, or {c-broadcast}, guarantees that all
+parties that do receive a particular broadcast receive the same
+value~\cite{malrei98a}. It does not, however, guarantee that all parties
+on the group receive anything in the first place.
+
+A {\em reliable broadcast}, or {\em r-broadcast}, additionally guarantees
+that all parties receive the broadcast~\cite{bracha84}. Our model being
+asynchronous, there is no guarantee about the time; the only guarantee is
+that if one honest party receives the broadcast, eventually all other ones
+will.
+
+An {\em atomic broadcast}~\cite{caslis99a,reiter94} primitive additionally
+guarantees that all honest parties receive all messages in the same order.
+This is a rather powerful synchronization mechanism, that deals with many
+uncertainties of the asynchronous network and the attackers. In principle,
+it is possible to build the entire database on top of such a protocol; for
+this paper, however, we have chosen dedicated protocols.
+
+\subsubsection{Threshold signatures.}
+
+Threshold signatures~\cite{shoup00a} allow parties to issue shares of a
+signature, which then -- given enough shares are available -- can be
+combined into one single signature. The nice property is that a threshold
+signature outputs the same constant length signature, independent of the
+actual number of parties or the subset of parties that did the actual
+signing. This not only preserves space and bandwidth, but also solves the
+key distribution system. A client does not need to know the public key of
+any individual pinger, nor the identity of the set of pingers, but can
+verify that a certain message was signed by a certain number of pingers by
+verifying against one, static, public key. The disadvantage is that the
+internal management of the group of pingers becomes more complex. If an
+old pinger is disabled, its key share must be invalidated. Similarly, a
+new pinger needs to get a new key-share, and all thresholds need to adapt.
+
+
+
+\subsection{The database update functions}
+
+Due to the different character of the data in the database,
+the pingers need four different protocols to maintain
+their databases in a consistent state.
+
+\subsubsection{Update set of mixes.}
+
+The main functionality of our protocols is to maintain a consistent
+set of mixes. Furthermore, a client should easily be able to obtain
+that set, i.e., each pinger can prove that he gives out the correct
+set. This is where the threshold signatures are used; there is only
+one signature for all pingers, but a minimum of two thirds are needed
+to generate the signature. Thus, a client only needs one public key
+to verify she got a correct set of mixes, without needing to know
+which parties are in the actual set of pingers.
+
+% FIXME -- I can't seem to get the LaTeX to like a \framebox here.
+% Let's put a rectangular frame around the Protocol UpdateMixes?
+\begin{algorithm}
+{\bf Protocol UpdateMixes}
+
+\begin{revpar}
+ \item r-broadcast new list ${\cal L}$ of mixes
+ \item wait for ($n-t$) r-broadcasts
+ \item {\bf receive} a set ${\cal L}'$ of mixes
+\end{revpar}
+\begin{revpar}
+ \item run multivalued BA protocol, using ${\cal L}'$ as an input
+ \item {\bf receive} a set ${\cal L}''$ of ($n-t$) lists
+ \item let ${\cal L}'''$ be the set of mixes that have been proposed by $t+1$
+ parties in the set
+ \item threshold-sign ({\em date}, ${\cal L}'''$) using a threshold signature
+ scheme, getting the signature share $\sigma_i$
+\end{revpar}
+
+\begin{revpar}
+ \item r-broadcast the signature share $\sigma_i$
+ \item wait for ($n-t$) such shares
+ \item combine the shares to retrieve $\sigma$
+\end{revpar}
+\end{algorithm}
+
+\subsubsection{Update set of pingers.}
+
+The protocol that updates the set of pingers is similar to the one that
+updates the set of mixes. However, for this protocol it is important to
+also update the shared keys, so that the old parties cannot participate
+in any signing process anymore, while the new parties get shares that
+allow them to participate. An appropriate re-sharing protocol is described
+in~\cite{CachinKLS02}.
+
+\subsubsection{Update database (externally).}
+
+With this function, the pingers can update information about a mix, most
+prominently its performance data. In the simplest case, this data is
+binary; in this case, a simple binary Byzantine agreement can be performed
+to determine a common value that has been proposed by at least one honest
+party. To avoid communication overhead, the agreements needed for all data
+on all mixes can be bundled; this leads to a protocol with message size
+linear in the total number of data items, and a running time logarithmic
+in the number of pingers.
+
+
+\subsubsection{Update database (internally).}
+
+This function is used to allow a mix to update database information about
+itself. Most commonly, this will be used to install a new key pair once
+the old one expires. It is relatively straightforward to implement this
+functionality, as the mix already has a key to authenticate itself.
+Assuming this is implemented properly (i.e., the signed messages are
+tagged properly), this can safely be used for database updates.
+
+The update protocol would be a simple {\em r-broadcast} of a signed
+message requesting the update. This way, it is guaranteed that all pingers
+receive the same request, and the database stays consistent. To avoid race
+conditions, the mix also needs to maintain a serial number, so that all
+parties can be assured to receive all updates in the same order. Note that
+there exist protocols that can also enforce that all pingers receive all
+update requests in the same order; however, implementing this here may be
+overkill.
+%
+% FIXME Klaus -- say something about why this is overkill?
+
+\subsection{Attack Model}
+
+It is known that
+a simple problem such as agreement is quite hard in an asynchronous
+environment if some parties crash or otherwise do not follow the protocol.
+The only way around is to either rely on timing assumptions, or to use a
+randomized algorithm.
+
+Our choice is for randomization, for two reasons: Firstly, the randomized
+model appears to be better adapted to the Byzantine setting, where the
+corrupted parties actively try to disrupt the protocol. Secondly, we can
+expect realistic attacker in our scenario to launch denial of service
+attacks on the network, which timing based protocols have difficulties
+dealing with.
+
+The price to pay for the fully asynchronous network model is a lower
+tolerance. It can easily be shown that nothing useful can be done once a
+third or more of all parties are corrupted.~\cite{FIXME} {\em FIXME, Klaus!}
+In the mix-net scenario, the
+main parties for the agreement protocols are the pingers; they need
+to agree on a consistent status of the mixes and then deliver it on
+request to the clients. As the clients should not be forced to
+contact more pingers than needed, each honest mix should be able to prove
+that the result it forwards to the client is in fact the genuine outcome
+of the agreement.
+
+
+\subsection{The Functionality}
+
+The primitives we have described can be utilized by the mix-net's independent components to perform basic network maintenance operations. Mixes can announce their existence to a small selection of pingers. After the pingers perform several instances of the UpdateMixes protocol, all the pingers will have learned the address of the new mixes and independently confirmed their validity by sending the mixes a query which will result in the automatic return of their keys. After verifying a new mix exists, adding the mix's keys (which have been obtained directly from the mix itself), and confirming that the mix is properly forwarding packets by sending pings through it, the pingers will add the new mix to their list of known mixes. Once enough pingers list the new mix and its operational details, it will be included in the consensus directory. The current Echolot pingers are able to add and remove mixes without human intervention, and Leuchtfeuer has been designed to integrate with the current pinger behavior.
+
+Leuchtfeuer restricts the information provided by pingers in one area where Echolot and the previously deployed pingers were unconstrained: in order to achieve consensus on the data associated with a mix, latency must be represented as one of a limited set of values, as opposed to being directly reported in units of time. Pingers should categorize individual mixes as being either ``high'' or ``low'' latency, and report them as such.
+
+Pingers using Leuchtfeuer will record reliability and performance information about the mixes as they currently do, though the interval between publication of updates available to mix clients will increase significantly. As opposed to being updated every five minutes, as is the current default in Echolot, Leuchtfeuer pingers will create a threshold signature on the consensus directory and publish the signed directory for the clients every 12 hours. While this potentially increases the risk of lost packets due to a mix going offline immediately after a consensus directory in which it was still listed is published, it limits the ability of a passive attacker to perform intersection attacks based on short-term pinger result fluctuations.
+
+Current mix clients do not perform any authentication on the data obtained by pingers, while in the Leuchtfeuer protocol, clients will need to verify the threshold signature to confirm that the consensus directory is authentic. This will not add noticeable additional complexity to the user experience.
+
+% \subsubsection{Protocols run by mixes:}
+% \paragraph{become\_mix:}
+% With this protocol, a new server tells the pingers that he would like
+ % to become a mix
+
+% Parameters: pub\_key
+% \paragraph{renounce\_mix:}
+% With this protocol, a mix announces he does not want to be a server
+% any more.
+
+% Parameters: signature on the message
+% \paragraph{update\_pubkey:}
+% This protocol is used by a mix to define a new public key.
+
+% \subsubsection{Protocols run by clients:}
+% \paragraph{get\_mix\_list:}
+
+% \subsubsection{Protocols run by pingers:}
+% \paragraph{suggest\_mix:}
+% \paragraph{output\_mix\_list:}
+% \paragraph{make\_pinger:}
+
+
\section{Conclusions and future work}
\label{conclusions}
@@ -407,13 +743,11 @@
reported by a pinger are accurate and comprehensive, and emphasized
specific technical requirements necessitated by the economic
considerations of the public anonymous remailer networks. We have
-implemented and released our own pinger software, which incorporates these
+implemented and released our own pinger software which incorporates these
techniques, and as a result has become the dominant pinger solution in use
on the Mixmaster network.
-In this paper we have not addressed the effects multiple independent pingers operating
-in the same mix-net can have on users' anonymity. This is an area in need of further
-evaluation.
+We have designed an agreement protocol suitable for use in the asynchronous setting presented by the public remailer networks, which enables mutually-untrusting pingers to come to present a unified view of the state of the remailer network, including the names, network addresses, and public keys of the existing mixes, which can be authenticated by the mix client by verifying just one cryptographic signature on the consensus data. Our protocol greatly restricts an attacker's ability to exploit information about a user's information service or directory to perform intersection attacks against him, and reduces the impact that pingers operated by an adversary can have on the mix-net.
@@ -427,14 +761,15 @@
and BiKiKii Admin, noisebox Admin and many nameless testers for providing
valuable feedback during Echolot's development.
-Len Sassaman would like to thank Bill Stewart, Nick Matthewson, and
+Len Sassaman would like to thank Bill Stewart, Nick Mathewson, and
numerous attendees of the erstwhile San Francisco Bay Area Cypherpunks
-meetings for their insightful discussions of the mechanics of pingers.
+meetings for their insightful discussions of the mechanics of pingers. We also thank
+Meredith L. Patterson for reviewing a draft of this paper and for providing helpful comments.
Len Sassaman's work was supported in part by the EU within the PRIME
Project under contract IST-2002-507591.
-\vfill\eject
+%\vfill\eject
\bibliographystyle{plain}
\bibliography{echolot}
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxx with
unsubscribe freehaven-cvs in the body. http://freehaven.net/