[freehaven-cvs] Expanded the section on Echolot, completed broadcast...

[rabbi@xxxxxxxx]

Update of /home2/freehaven/cvsroot/doc/pingers
In directory moria:/tmp/cvs-serv24802

Modified Files:
	pingers.tex 
Log Message:
Expanded the section on Echolot, completed broadcast protocols 
definitions, removed author names.


Index: pingers.tex
===================================================================
RCS file: /home2/freehaven/cvsroot/doc/pingers/pingers.tex,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -d -r1.4 -r1.5
--- pingers.tex	9 Mar 2006 11:41:18 -0000	1.4
+++ pingers.tex	9 Mar 2006 17:50:17 -0000	1.5
@@ -17,17 +17,20 @@
 \renewcommand\labelitemi{\normalfont\bfseries --}
 \renewcommand\labelitemii{$\m@th\bullet$}
 
-\title{Measuring Remailer Reliability}
+\title{Echolot and Leuchtfeuer: Measuring the Reliability of Unreliable Mixes}
 
-\author{Len Sassaman\inst{1}}
-\author{Klaus Kursawe\inst{1}}
-\author{Peter Palfrader\inst{2}}
+% Blinded for submission
+
+%\author{Len Sassaman\inst{1} and Klaus Kursawe\inst{1} and Peter Palfrader\inst{2}
 
 %foo
 
-\institute{Katholieke Universiteit Leuven \\
-Kasteelpark Arenberg 10, B-3001 Leuven-Heverlee, Belgium
-\email{\{len.sassaman\}@esat.kuleuven.be}
+%\institute{Katholieke Universiteit Leuven \\
+%Kasteelpark Arenberg 10, B-3001 Leuven-Heverlee, Belgium
+%\email{\{len.sassaman,klaus.kursawe\}@esat.kuleuven.be}
+%\and
+%\institute{Universit\"at Salzburg %\\ FIXME -- address below!
+%\email{\{ppalfrad\}@cosy.sbg.ac.at}
 
 %foo
 
@@ -43,9 +46,9 @@
 
 In a network of distributed mix-net servers, information regarding the
 network health and operational behavior of the individual nodes must be
-made available to the client applications which generate messages for use
-in the mix-network. We present a summary of the techniques currently in
-use, and evaluate their methods.
+made available to the client applications, to select reliable nodes to use
+in each message's path through the mix-network. We present a summary of
+the techniques currently in use, and evaluate their methods.
 
 We evaluate the security concerns regarding an information service,
 including the issues regarding anonymity set preservation, information
@@ -87,6 +90,50 @@
 networks. As of this writing, there are nineteen Echolot pingers in
 operating publicly~\cite{allpingers}.
 
+\subsubsection{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,
+allowing the mix clients to make as much use of the available network
+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
+messages encrypted using the network-specific packet format, and the
+response times and success rates are tallied. These results allow the mix
+client to make general assumptions about the overall behavior of the node
+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
+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 occuring at the link between the two nodes. Thus, either
+remailer can be reliably used, as long as they are not selected to be
+adjacent nodes in the message path. Likewise, the latency value calculated
+from the transmission of a chain ping until its return at the pinger
+measures the combined latency of the two nodes. If this is significantly
+different than the sum of the single-ping latencies for each node, the
+mix-net client can make determinations about the suitability of that
+pairing of nodes in a chain.
+
+\subsubsection{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
+to the other nodes in the network. In the case of Mixmaster, there is no
+central control structure for tracking the existence of functional nodes,
+and the components in the system must devise a way of obtaining this
+information. Often, the human operator of a node joining or exiting the
+network will announce the status change to other node operators and users
+via the ``remops'' mailing list or by posting to USENET. Just as often,
+nodes will come into existence or cease operation without any warning or
+notification at all.
+
+% unfinished -- Len's working on this, leave notes, but leave until last to write it up.
+%
+%
+
 \subsubsection{Echolot algorithm}
 
 In order to test remailer A's reliability, Echolot sends an encrypted ping
@@ -199,6 +246,8 @@
 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
+
 \section{Anonymity set attacks based on pinger data}
 
 A mix network in which users obtain their view of the network's heath and
@@ -230,7 +279,9 @@
 problem, and introduces additional reliability constraints on the quality
 of the pinger information.
 
-\section{Unified directory view}
+% More attacks?
+
+\section{Leuchtfeuer: a unified directory view}
 
 The solution to the partitioning attacks mentioned in the previous section
 involves providing all clients with the same view of the network. Each
@@ -504,7 +555,11 @@
 e.g., that it is signed by someone.
 
 \subsection{Broadcast protocols}
- Broadcast protocols are used to 
+
+Broadcast protocols are used to send a message to a number of receivers.
+If the sender and/or the network cannot be trusted, more complex
+techniques have to be used to ensure properties required by higher level
+protocols.
 
 A {\em consistend broadcast}, or {c-broadcast}, guarantees that all
 parties that do receive a particular broadcast recieve the same value. It
@@ -515,6 +570,13 @@
 that all parties receive the broadcast. Our model being asynchronous,
 there is no guarantee about the time; the only guarantere is that if one
 honest party receives the broadcast, eventually all other ones will.
+
+An {\em atomic broadcast}, or {\em a-cast}, also ensures that all honest
+parties receive all broadcasted messages in the same order. This is a
+rather powerfull primitive, as it deals with the worst effects of an
+asynchronous network and allows for an easy implementation of a replicated
+state machine, ensuring all replicas perform all updates in the same
+order.
  
 
 \subsection{Threshold signatures} 
@@ -564,6 +626,8 @@
 \section{Conclusions and future work}
 \label{conclusions}
 
+% WRITE ME
+
 \subsection*{Acknowledgments}
 
 

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