[freehaven-cvs] spelling

[rabbi@xxxxxxxx]

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

Modified Files:
	leuchtfeuer.tex 
Log Message:
spelling


Index: leuchtfeuer.tex
===================================================================
RCS file: /home2/freehaven/cvsroot/doc/pingers/leuchtfeuer.tex,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- leuchtfeuer.tex	11 Mar 2006 18:30:54 -0000	1.2
+++ leuchtfeuer.tex	11 Mar 2006 18:46:04 -0000	1.3
@@ -78,9 +78,9 @@
 \label{pingers}
 
 Mix-nets are intended to protect users' anonymity and conceal their communication patterns.
-In a distributed-trust anonymity system such as this, the user must trust that the \emph{system} will provide these protections, but is not required to trust all of the individual nodes themselves. Mix-nets consist of \emph{mixes} which accept input traffic in the form of messages encrypted to the mix's public key, then they delay and reorder the traffic, and forward it onward to its pre-addressed destination. Messages are sent through user-selected\footnote{Or client-selected.} chain of mixes, with each message typically encrypted and addressed, in a nested fashion, to three to five mixes in the mix-net.The security of the system is based on the premise that a user's traffic may be safely routed through nodes which the attacker controls, as long as the user's client has selected a path through the network that includes a sufficient number of honest nodes. Multiple distributed-trust mix-net variants have been deployed on the Internet since the early 1990's. 
+In a distributed-trust anonymity system such as this, the user must trust that the \emph{system} will provide these protections, but is not required to trust all of the individual nodes themselves. Mix-nets consist of \emph{mixes} which accept input traffic in the form of messages encrypted to the mix's public key, then they delay and reorder the traffic, and forward it onward to its pre-addressed destination. Messages are sent through user-selected\footnote{Or client-selected.} chains of mixes, with each message typically encrypted and addressed, in a nested fashion, to three to five mixes in the mix-net. The security of the system is based on the premise that a user's traffic may be safely routed through nodes which the attacker controls, as long as the user's client has selected a path through the network that includes a sufficient number of honest nodes. Multiple distributed-trust mix-net variants have been deployed on the Internet since the early 1990's. 
 
-The components of the extant mix-nets are operated on a volunteer basis, often by parties unknown to the users. Since many volunteer operators lack the resources to offer the same level of high-availabilty access assurance as commercial network service providers, and individual mixes may come and go as the circumstances facilitating their volunteer operation change, it is essential that users of the mix-net be able to learn a current list of available, correctly-performing mixes, and their corresponding public keys, so that their messages will be delivered reliably and swiftly. 
+The components of the extant mix-nets are operated on a volunteer basis, often by parties unknown to the users. Since many volunteer operators lack the resources to offer the same level of high-availability access assurance as commercial network service providers, and individual mixes may come and go as the circumstances facilitating their volunteer operation change, it is essential that users of the mix-net be able to learn a current list of available, correctly-performing mixes, and their corresponding public keys, so that their messages will be delivered reliably and swiftly. 
 
 The first reliability servers for mix-nets to be deployed~\cite{rlist} existed to provide information about the Cypherpunk remailer network~\cite{hal-remailer}, and are known to users and operators of email-oriented mixes (or \emph{remailers}) as \emph{pingers}. While there have been multiple pingers written for the Cypherpunk and Mixmaster~\cite{mixmaster-spec} remailer networks over the last decade, more than two-thirds of the pingers currently in operation are running Echolot~\cite{echolot}.
 
@@ -115,7 +115,7 @@
 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 cose. If the information provided by both pingers differend in
+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
@@ -156,10 +156,10 @@
 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 a
-distribured systems against faulty parties~\cite{schnei90,deblfa91}.  In the
+distributed systems against faulty parties~\cite{schnei90,deblfa91}.  In the
 Mixes scenario, the main parties for the agreement protocols are the {\em
 pingers}, i.e., the parties that maintain a database on the active mixes,
-thier authentication keys and some of their properties.  They need to
+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
@@ -172,7 +172,7 @@
 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
-recogise they are in a bad condition and alert the aministrator, but it is
+recognise 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
 dishonest, this may place quite some burden on the administration.
@@ -199,21 +199,21 @@
 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 imput values; in our case, this means it
+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 an
+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 bitstring, rather than only a binary value.  As there is a
-(potentially) invinite universe of possible values, a multivalued
+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 thevaule prior to
+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.
@@ -221,28 +221,28 @@
 \subsubsection{Broadcast protocols.}
 
 Broadcast protocols~\cite{ckps01} are used to send messages from one
-sender to a number of receivers. In the simnplest version, the sender
+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 consistend broadcast}, or {c-broadcast}, guarantees that all
-parties that do receive a particular broadcast recieve the same
+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 reveive anything in the first place.
+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 guarantere is
+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 powerfull synchronisation mechanism, that deals with many
-uncertaincies of the asynchronous network and the attackers. In principal,
+This is a rather powerful synchronization mechanism, that deals with many
+uncertainties of the asynchronous network and the attackers. In principal,
 it is possible to build the entire database on top of such a protocol; for
 this paper, however, we have chosen dedicated protocols.
  
@@ -250,17 +250,17 @@
 
 Threshold signatures~\cite{shoup00a} allow parties to issue shares of a
 signature, which then -- given enough shares are available -- can be
-combine to one single signature. The nice property is that a threshold
+combined into one single signature. The nice property is that a threshold
 signature outputs the same constant length signature, independent of the
-actuall number of parties or the subset of parties that did the actuall
-signing. This not only preserves space and bandwith, but also solves 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 disabeled, its key share must be invalidated. Similary, a
-new pinger needs to get a new keyshare, and all thresholds need to adapt.
+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.
 
 
 
@@ -272,12 +272,12 @@
 
 \subsubsection{Update set of mixes.}
 
-The main functionallity of our protocols is to maintain a consistend
+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 ony public key
+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.
 
@@ -312,34 +312,34 @@
 updates the set of mixes. However, for this protocol it is important to
 also update the shared keys, so that the old parties can not participate
 in any signing process anymore, while the new parties get shares that
-allow them to participate. An appropriate resharing protocol is described
+allow them to participate. An appropriate re-sharing protocol is described
 in~\cite{CachinKLS02} ;
 
-\subsubsection{Update database (externally.)}
+\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 bundeled; this leads to a protocol with message size
+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.)}
+\subsubsection{Update database (internally).}
 
 This function is used to allow a mix to update database information about
 himself. Most commonly, this will be used to install a new key pair once
 the old one expires.  It is relatively straightforward to implement this
-functionallity, as the mix already has a key to authenticate itself.
+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 savely be used for database updates.
+tagged properly), this can safely be used for database updates.
 
 The update protocol would be a simple {\em r-broadcast} of the 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
-condidions, the mix also needs to maintain a serial number, so that all
+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 the all pingers receive all
 update requests in the same order; however, implementing this here may be
@@ -353,16 +353,16 @@
 The only way around is to either rely on timing assumptions, or to use a
 randomized algorithm.
 
-Our choice is for randomization, for teo reasons: Firstly, the randomised
-model appears to be better adapted to the byzantine setting, where the
+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 usefull can be done once a
-third or more of all parties are corrupted. In the Mixes scenario, the
+tolerance. It can easily be shown that nothing useful can be done once a
+third or more of all parties are corrupted. In the mixes scenario, the
 main parties for the agreement protocols are the {\em pingers}; 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
@@ -371,8 +371,8 @@
 of the agreement.
 
 
-\subsection{The Functionallity}
- Protocols Run by mixes:
+\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
@@ -382,17 +382,17 @@
     With this protocol, a mix announces he does not want to be a server 
     any more.
     
-    Paramters: signature on the message 
-  \paragraph{update\_pubkey}
+    Parameters: signature on the message 
+  \paragraph{update\_pubkey:}
     This protocol is used by a mix to define a new public key.
 
- Protocols run by clients
-   \paragraph{get\_mix\_list}
+ \subsubsection{Protocols run by clients:}
+   \paragraph{get\_mix\_list:}
 
- 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}

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