[freehaven-cvs] Finish section 4.4, conclusion.

[rabbi@xxxxxxxx]

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

Modified Files:
	leuchtfeuer.tex 
Log Message:
Finish section 4.4, conclusion.


Index: leuchtfeuer.tex
===================================================================
RCS file: /home2/freehaven/cvsroot/doc/pingers/leuchtfeuer.tex,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -d -r1.5 -r1.6
--- leuchtfeuer.tex	11 Mar 2006 19:19:24 -0000	1.5
+++ leuchtfeuer.tex	11 Mar 2006 20:11:44 -0000	1.6
@@ -350,7 +350,7 @@
 
 \subsection{Attack Model}
 
-Since the infamous FLP impossibility proof~\cite{FLP85}, it is known that
+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
@@ -375,32 +375,41 @@
 
 
 \subsection{The Functionality}
- \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.
+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 publish the consensus directory for 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.
+%    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 clients:}
+%   \paragraph{get\_mix\_list:}
 
- \subsubsection{Protocols run by pingers:}
- \paragraph{suggest\_mix:}
- \paragraph{output\_mix\_list:}
- \paragraph{make\_pinger:}
+% \subsubsection{Protocols run by pingers:}
+% \paragraph{suggest\_mix:}
+% \paragraph{output\_mix\_list:}
+% \paragraph{make\_pinger:}
 
 \section{Conclusions and future work}
 \label{conclusions}
 
-% WRITE ME
+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.
 
 \subsection*{Acknowledgments}
 

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