[freehaven-cvs] Finish merge, put attacks in the right place.

[rabbi@seul.org]

Update of /home2/freehaven/cvsroot/doc/pynchon-gate
In directory moria.mit.edu:/tmp/cvs-serv18274

Modified Files:
	pynchon.tex 
Log Message:
Finish merge, put attacks in the right place.


Index: pynchon.tex
===================================================================
RCS file: /home2/freehaven/cvsroot/doc/pynchon-gate/pynchon.tex,v
retrieving revision 1.48
retrieving revision 1.49
diff -u -d -r1.48 -r1.49
--- pynchon.tex	18 Sep 2004 01:00:05 -0000	1.48
+++ pynchon.tex	18 Sep 2004 01:27:26 -0000	1.49
@@ -292,182 +292,6 @@
 interest, and provides a way to attack the security of the
 system~\cite{harmful}.
 
-\subsection{Known attacks against pseudonymity systems}
-\label{subsec:known-attacks}
-%XXXX writeme
-We discuss the security implications in pseudonymity systems throughout
-this paper. Most attacks on pseudonymity systems fall into one of the
-following categories.
-
-\subsubsection{Legal and hacking attacks.}
- Attackers may attempt to coerce the operators of pseudonymity systems
-through lawsuits or other means, or may attempt to surreptitiously obtain
-information about nym holders. Systems should be designed so that such
-information cannot be obtained.
-
-The Pynchon Gate protects against these attacks by using encryption keys
-for the nym accounts to encrypt incoming messages. Nym holders do not
-communicate directly with the nym server, and the nym server is not
-entrusted with any identifying information for the user. All data in the
-tree structure is deleted from the collator after being passed to the
-distributors. This ensures that the collator has as little information
-useful to an attacker as possible, and that collator resource requirements
-are kept low.
-
-\subsubsection{Mix attacks.} 
-Systems based on the mix-net primative must be concerned with attacks
-against the underlying mix-network, as they rely upon it for security.
-Additionally, reply-block-based nym server systems require additional
-security properties that normal mix-net systems may not have~\cite{minx}.
-
-The Pynchon Gate uses mix-nets for forward message delivery only. Attacks
-which do not work against a mix-net in normal forward-delivery mode will
-not impact Pynchon Gate.
-
-\subsubsection{Replay attacks.}
-An attacker capable of monitoring the communications network may attempt
-to obtain information about nym holders by comparing network and user
-behavior when a given message or packet is transmitted multiple times.
-
-The Pynchon Gate uses TLS when communicating between components and the
-client, so that data is encrypted with a short-lived session key. The
-topology of the Pynchon Gate infrastructure further eliminates areas of
-potential replay attack risk.
-
-\subsubsection{Tagging and known-cleartext attacks.} An attacker may alter
-a message, or observe the cleartext of a message, so that he may be able
-to later link an input message with a given output retrieved by the
-nym holder.
-
-The Pynchon Gate's message and link encryption prevents an attacker from
-observing the cleartext of a message. Tagging attacks are ineffective, as
-the data transfered to the user from the distributors appears random. The
-metaindex provides the client with the hash of the index bucket. Each
-message bucket provides the hash of the next message bucket, and with this
-information, the client can verify the integrity of information downloaded
-from distributors and respond to garbled data without leaking information
-about which bucket it was requesting.
-
-\subsubsection{"{\it Who am I?}" attack.} 
-An attacker may send messages intended for nym Alice to nym Bob instead,
-to confirm that Alice and Bob are the same nym holder~\cite{gd-thesis}.
-
-This attack relies primarily upon the ability to link one nym, $Alice_1$,
-with another nym, $Alice_2$, by sending a message encrypted with
-$Alice_1$'s reply block to $Alice_2$'s address. The architecture of
-Pynchon by the nature of its design avoids this, though a similar social
-engineering attack may be performed if the nym holder is using a separate
-message encryption protocol such as PGP~\cite{rfc-2440}. More research
-needs to be done in the area of privacy-preserving human-computer
-interaction.
-
-% Also: social engineering; traffic analysis; leave/join attacks...
-
-\subsubsection{Usage pattern and intersection attacks.}
-
-An attacker may analyze network usage and anonymity set members over time
-to sub-divide anonymity sets such that a given user is identified. In
-addition to passive observation of the network, there are a number of
-active attacks which can facilitate usage pattern attacks. An attacker may
-flood a nym, to observe a corresponding increase in traffic by the
-recipient. If attacks on portions of the pseudonymity infrastructure
-affect some users differently than others, an attacker may exploit such
-attacks on components of the system to facilitate an intersection attack
-against a user of the system as a whole. For instance, in a reply-block
-system, an attacker could disable certain mixes, and observe which nyms
-ceased receiving traffic. If the nym holder has a fixed-route reply block,
-this would enable the attacker to identify the mixes used in the
-nym holder's reply-block path, and increase his chances of successfully
-linking the nym with the nym holder's true name.
-
-Users of the Pynchon Gate select distributors from which to receive data
-at random, each time the nym holder retrieves her messages. As opposed to
-systems where the pseudonym infrastructure initiates the delivery of
-messages, the Pynchon Gate Client initiates the retrival of messages, and
-thus message retrieval cannot be correlated to a given nym by a malicious
-sender. 
-
-Message buckets are of a fixed size, to protect against attacks similar to
-the active flooding attacks on mix-net systems~\cite {trickle02} as well
-as simple usage pattern analysis. Delivery of excess messages for a given
-nym account may be conducted by \emph{trickling} the pending messages to
-the distributors over the next several tree distributions. If a client
-will be retrieving large amounts of data on a regular basis, this method
-will not work. Instead, the client should at account creation time request
-a sufficient number of buckets to receive all data destined to it. Pending
-data queued on the collator should be expired after a reasonable amount of
-time.
-
-A hash tree of variable depth would risk leaking usage information about
-nym-holders. The Pynchon Gate uses a tree of a fixed depth.
-
-Since the time between the delivery of a message to the nym server and a
-reply from the nym holder may leak information about the nym holder to an
-observer, traffic from the client to the distributors is regulated by the
-client, which queries the distributors only at given intervals. The
-intervals chosen are random within the message window, to thwart active
-attacks against the distributor targetting a specific client.
-%XXXX Fix this in design.
-
-\subsection{Statistical disclosure against reply-block-based nym servers}
-\label{subsec:disclosure}
-Nym servers based on reply blocks (discussed in Section
-\ref{subsec:related-work} above) are currently the most popular option for
-receiving messages pseudonymously.  Nevertheless, they are especially
-vulnerable to end-to-end traffic analysis.
-
-Suppose an adversary is eavesdropping on the nym server, and on all
-recipients.  The attacker wants to know which user (call her Alice) is
-associated with a given pseudonym (say, {\tt nym33}).  The adversary can
-mount an {\it intersection attack}, by noticing that Alice receives more
-messages, on average, after the nym server has
-received a message for {\tt nym33} than when it has not.\footnote{This
-  task is especially easy if the adversary can distinguish reply messages
-  from non-reply messages, as is possible with Type I remailers.}
-Over time, the adversary will notice that this correlation holds for Alice
-but not for other users, and deduce that Alice is likely associated with {\tt
-  nym33}.
-
-Recent work~\cite{statistical-disclosure,e2e-traffic} has studied the use of an
-implementation of these intersection attacks called ``Statistical
-Disclosure,'' where an attacker compares network behavior when Alice has sent
-to network when she is absent in order to link an {\it anonymous} sender
-Alice to her regular
-recipients $\mbox{Bob}_1 ...  \mbox{Bob}_N$.   Against {\it pseudonymous}
-recipients, however, these attacks are significantly easier: in the anonymity
-case we assume that many senders may send to any given recipient
-$\mbox{Bob}_i$, but with pseudonymous delivery, we only one
-user sends or receives messages for a given pseudonym.  This additional
-linkability makes the attack converge more quickly.
-
-To examine this effect, we ran a modified version of the attack simulations
-described in~\cite{e2e-traffic}, assuming a single target pseudonym and $N$
-non-target pseudonyms providing cover.  In order to make the attacker's job
-as difficult as possible (and thus establish an upper bound for security), we
-assume that all users behave identically: they receive messages with equal
-probability according to independent geometric distributions in each unit of
-time (receiving no messages with probability $1-P_M$); they each use
-identical reply blocks with path length $\ell$ through mixes in a steady
-state that delay each message each round with probability $P_D$.
-
-We ran the simulated attack with different values for $P_M$, $P_D$, and
-$\ell$, against a nym server with $N=2^{16}$ active pseudonymous users.
-(This is probably an overestimate of the number of users on typical nymserver
-today~\cite{nym-alias-net}.)   We performed 100 trials for each set of
-paramaters.  In the worst case (for the nym holder), when
-$P_M=0.5, \ell=1, P_D=0.1$, the lack of
-mix-net delay variance allowed the simulated
-attacker to guess the user's identity correctly after the user received an
-average of only 37 messages.  In the best simulated case ($P_M=0.5,
-P_D=0.9,\ell=4$), the user was able to receive an average of only 1775
-messages before the attacker guessed correctly.  For an active user, this is
-well within a month's expected traffic.
-
-Although there are various proposals to use dummy traffic to resist
-statistical disclosure attacks, these difficult to implement perfectly in
-practice (due to outages and so forth) and even slight imperfections render
-users vulnerable to attack~\cite{e2e-traffic}.
-
 \section{The Pynchon Gate Design}
 \label{sec:design}
 We present a design framework for The Pynchon Gate. A detailed
@@ -564,29 +388,6 @@
 Finally, the nymserver also generates an different independent identifier for
 each user, every cycle: $\UserID{}[i] = H(S[i] | \mbox{\tt "USER ID"})$.
 
-%Messages sent from the nym server to the nym owner are
-%addressed at the collator to an opaque id which remains unchanged for the
-%nym. The actual messages include the iteration number of the dynamic key
-%in the clear, and the messages for the nym user are encrypted and MAC'd
-%using that iteration of the dynamic key:
-%$\UserID{}[i] = H(S[i] | \mbox{\tt "USER ID"})$
-
-%Dynamic key rotation allows us to achieve forward secrecy. Without dynamic
-%key rotation it would be trivial for an attacker to archive all data sent
-%to distributors, and then at some later time obtain the nym's collator
-%address and key from the nym server though an active attack on those
-%components. The attacker would then be able to read all messages that nym
-%has ever received.
-
-%In the interest of retaining little information for an attacker,
-%implementations should discard old secrets \emph{as soon as they are no
-%longer needed.} Thus, at the start of each cycle i, a nymserver should
-%derive $S[i+1]$, $\UserID{}[i]$, and $\SUBKEY(0,i)$, and immediately discard
-%$S[i]$.
-%After using each $\SUBKEY(j,i)$, the nymserver should calculate $\SUBKEY(j+1,i)$
-%and discard $\SUBKEY(j,i)$.  After each cycle, the nymserver should discard
-%the last $\SUBKEY(j,i)$, and $\UserID{}[i]$.
-
 \subsection{The Collator}
 
 At the end of each cycle, the nym server passes messages to the {\it
@@ -665,8 +466,8 @@
 of the servers.
 
 The protocol runs as follows: after choosing distributors, the client
-establishes an encrypted to each
-(say, using TLS).  These connections must be unidirectionally authenticated
+establishes an encrypted session to each
+(e.g., using TLS).  These connections must be unidirectionally authenticated
 to prevent man-in-the-middle attacks, and can be made sequentially, or in
 parallel.
 
@@ -712,63 +513,237 @@
 %which has been proposed as the basis for the Mixminion nym
 %servers~\cite{imap-over-minion}.}
 
-\section{Security Concerns}
-\label{sec:security}
-As with any anonymity system, care must be taken at all steps to prevent
-possible attacks on the effective anonymity provided.
-%
-%In order to protect against usage pattern attacks, it is imperative that
-%the tree depth be the same for all leaf nodes.
+\subsection{Known attacks against pseudonymity systems}
+\label{subsec:known-attacks}
+We discuss the security implications in pseudonymity systems throughout
+this paper. Most attacks on pseudonymity systems fall into one of the
+following categories.
 
-The collator is responsible for publishing tree metadata. This metadata
-includes the individual size of each bucket, the
-total number of buckets, and a hash tree root which can be used to verify
-the integrity of any bucket individually. Clients must obtain this
-information before initiating the message retrieval protocol with the
-distributors. This metadata must be published widely to prevent either the
-collator or any of the distributors from attacking clients by tricking
-them into thinking that the hash root of the tree is something other than
-what all of the other clients know it to be, or by making a tree with
-varying leaf depths. Distributors should do basic sanity checks, such as
-verifying tree integrity and that all of the leaves are at the same depth.
-The distributors should also send audit messages of their own to verify
-that the messages correctly appear in the system. Finally, clients should
-make sure that each of the distributors they use agree about the value of
-the hash root.
+\subsubsection{Legal and hacking attacks.}
+Attackers may attempt to coerce the operators of pseudonymity systems
+through lawsuits or other means, or may attempt to surreptitiously obtain
+information about nym holders. Systems should be designed so that such
+information cannot be obtained.
 
-%The hash tree root used for bucket authentication uses a distinct tree
-%structure from the tree organization of the data in the buckets. The
-%authentication tree is a simple binary hash tree which can be computed
-%implicitly given the entire list of buckets. Binary hash trees enable the
-%path from any given bucket to the root to be expressed as compactly as
-%possible.
-% XXXX This is not correct.
+The Pynchon Gate protects against these attacks by using encryption keys
+for the nym accounts to encrypt incoming messages. Nym holders do not
+communicate directly with the nym server, and the nym server is not
+entrusted with any identifying information for the user. All data in the
+tree structure is deleted from the collator after being passed to the
+distributors. This ensures that the collator has as little information
+useful to an attacker as possible, and that collator resource requirements
+are kept low.
 
-Distributors append to each bucket the path from that bucket to the hash
-tree root. With this information, the client can verify the integrity of
-information downloaded from distributors and respond to garbled data
-without leaking information about which bucket it was requesting.
+Messages sent from the nym server to the nym owner are
+addressed at the collator to an opaque id which remains unchanged for the
+nym. The actual messages include the iteration number of the dynamic key
+in the clear, and the messages for the nym user are encrypted and MAC'd
+using that iteration of the dynamic key:
+$\UserID{}[i] = H(S[i] | \mbox{\tt "USER ID"})$
 
-Message buckets must be of a fixed size in order to protect against
-attacks similar to the active flooding attacks on mix-net systems~\cite
-{trickle02} as well as simple usage pattern analysis. Delivery of excess
-messages for a given nym account may be conducted by \emph{trickling} the
-pending messages to the distributors over the next several tree
-distributions. If a client will be retrieving large amounts of data on a
-regular basis, this method will not work. Instead, the client should at
-account creation time request a sufficient number of buckets to receive
-all data destined to it. Pending data queued on the collator should be
-expired after a reasonable amount of time.
+Dynamic key rotation allows us to achieve forward secrecy. Without dynamic
+key rotation it would be trivial for an attacker to archive all data sent
+to distributors, and then at some later time obtain the nym's collator
+address and key from the nym server though an active attack on those
+components. The attacker would then be able to read all messages that nym
+has ever received.
 
-All data in the tree structure is deleted from the collator after being
-passed to the distributors. This ensures that the collator has as little
-information useful to an attacker as possible, and that collator resource
-requirements are kept low.
+In the interest of retaining little information for an attacker,
+implementations should discard old secrets \emph{as soon as they are no
+longer needed.} Thus, at the start of each cycle i, a nymserver should
+derive $S[i+1]$, $\UserID{}[i]$, and $\SUBKEY(0,i)$, and immediately discard
+$S[i]$.
+After using each $\SUBKEY(j,i)$, the nymserver should calculate $\SUBKEY(j+1,i)$
+and discard $\SUBKEY(j,i)$.  After each cycle, the nymserver should discard
+the last $\SUBKEY(j,i)$, and $\UserID{}[i]$.
 
-Traffic from the client to the distributors should be regulated in a
-manner which prevents a local observer from determining any usage pattern
-information about the nym owner. This can be achieved by allowing the
-client to query the distributors only at regular intervals.
+\subsubsection{Mix attacks.} 
+Systems based on the mix-net primative must be concerned with attacks
+against the underlying mix-network, as they rely upon it for security.
+Additionally, reply-block-based nym server systems require additional
+security properties that normal mix-net systems may not have~\cite{minx}.
+
+The Pynchon Gate uses mix-nets for forward message delivery only. Attacks
+which do not work against a mix-net in normal forward-delivery mode will
+not impact Pynchon Gate.
+
+\subsection{Man-in-the-middle attacks.}
+An attacker able to pose as a component in the system may be able to learn
+information about the users of the system. Authentication of the
+components should be performed to prevent such attacks.
+
+To prevent man-in-the-middle attacks against the distributors, TLS is used
+as the protocol's transport layer~\cite{rfc-2246}. Users negotiate a TLS
+connection with a given distributor, and then relay PIR messages as
+described. The connection is authenticated using a certificate in a
+two-level certificate chain. The top-level certificate is a self-signed
+long-term certificate for the distributor. The second-level certificate is
+used to authenticate the distributor and establish the TLS session for the
+PIR protocol, and should be rotated regularly to provide forward secrecy.
+
+\subsubsection{Replay attacks.}
+An attacker capable of monitoring the communications network may attempt
+to obtain information about nym holders by comparing network and user
+behavior when a given message or packet is transmitted multiple times.
+
+The Pynchon Gate uses TLS when communicating between components and the
+client, so that data is encrypted with a short-lived session key. The
+topology of the Pynchon Gate infrastructure further eliminates areas of
+potential replay attack risk.
+
+\subsubsection{Tagging and known-cleartext attacks.} An attacker may alter
+a message, or observe the cleartext of a message, so that he may be able
+to later link an input message with a given output retrieved by the
+nym holder.
+
+The Pynchon Gate's message and link encryption prevents an attacker from
+observing the cleartext of a message. Tagging attacks are ineffective, as
+the data transfered to the user from the distributors appears random. The
+metaindex provides the client with the hash of the index bucket. Each
+message bucket provides the hash of the next message bucket, and with this
+information, the client can verify the integrity of information downloaded
+from distributors and respond to garbled data without leaking information
+about which bucket it was requesting.
+
+\subsubsection{"{\it Who am I?}" attack.} 
+An attacker may send messages intended for nym Alice to nym Bob instead,
+to confirm that Alice and Bob are the same nym holder~\cite{gd-thesis}.
+
+This attack relies primarily upon the ability to link one nym, $Alice_1$,
+with another nym, $Alice_2$, by sending a message encrypted with
+$Alice_1$'s reply block to $Alice_2$'s address. The architecture of
+Pynchon by the nature of its design avoids this, though a similar social
+engineering attack may be performed if the nym holder is using a separate
+message encryption protocol such as PGP~\cite{rfc-2440}. More research
+needs to be done in the area of privacy-preserving human-computer
+interaction.
+
+% Also: social engineering; traffic analysis; leave/join attacks...
+
+\subsubsection{Usage pattern and intersection attacks.}
+
+An attacker may analyze network usage and anonymity set members over time
+to sub-divide anonymity sets such that a given user is identified. In
+addition to passive observation of the network, there are a number of
+active attacks which can facilitate usage pattern attacks. An attacker may
+flood a nym, to observe a corresponding increase in traffic by the
+recipient. If attacks on portions of the pseudonymity infrastructure
+affect some users differently than others, an attacker may exploit such
+attacks on components of the system to facilitate an intersection attack
+against a user of the system as a whole. For instance, in a reply-block
+system, an attacker could disable certain mixes, and observe which nyms
+ceased receiving traffic. If the nym holder has a fixed-route reply block,
+this would enable the attacker to identify the mixes used in the
+nym holder's reply-block path, and increase his chances of successfully
+linking the nym with the nym holder's true name.
+
+Users of the Pynchon Gate select distributors from which to receive data
+at random, each time the nym holder retrieves her messages. As opposed to
+systems where the pseudonym infrastructure initiates the delivery of
+messages, the Pynchon Gate Client initiates the retrival of messages, and
+thus message retrieval cannot be correlated to a given nym by a malicious
+sender. 
+
+Message buckets are of a fixed size, to protect against attacks similar to
+the active flooding attacks on mix-net systems~\cite {trickle02} as well
+as simple usage pattern analysis. If the number of messages contained in
+the system is too great to return in this normalized manner, delivery may
+be conducted by \emph{trickling} the pending messages to the distributors
+over the next several tree distributions. To protect against denial of
+service attacks, a notation must be included in the data from the collator
+indicating that there are further messages waiting as well as the size of
+the pending data to be delivered. The client may then send administrative
+requests via an anonymous email message to the collator indicating whether
+the pending messages should be delivered or discarded.\footnote{If a
+client will be retrieving large amounts of data on a regular basis, this
+method will not work. Instead, the client should at account creation time
+request a sufficient number of buckets to receive all data destined to it.
+Pending data queued on the collator should be expired after a reasonable
+amount of time.}
+
+A hash tree of variable depth would risk leaking usage information about
+nym-holders. The Pynchon Gate uses a tree of a fixed depth.
+
+Since the time between the delivery of a message to the nym server and a
+reply from the nym holder may leak information about the nym holder to an
+observer, traffic from the client to the distributors is regulated by the
+client, which queries the distributors only at given intervals. The
+intervals chosen are random within the message window, to thwart active
+attacks against the distributor targetting a specific client.
+%XXXX Fix this in design.
+
+\subsection{Statistical disclosure against reply-block-based nym servers}
+\label{subsec:disclosure}
+Nym servers based on reply blocks (discussed in Section
+\ref{subsec:related-work} above) are currently the most popular option for
+receiving messages pseudonymously.  Nevertheless, they are especially
+vulnerable to end-to-end traffic analysis.
+
+Suppose an adversary is eavesdropping on the nym server, and on all
+recipients.  The attacker wants to know which user (call her Alice) is
+associated with a given pseudonym (say, {\tt nym33}).  The adversary can
+mount an {\it intersection attack}, by noticing that Alice receives more
+messages, on average, after the nym server has
+received a message for {\tt nym33} than when it has not.\footnote{This
+  task is especially easy if the adversary can distinguish reply messages
+  from non-reply messages, as is possible with Type I remailers.}
+Over time, the adversary will notice that this correlation holds for Alice
+but not for other users, and deduce that Alice is likely associated with {\tt
+  nym33}.
+
+Recent work~\cite{statistical-disclosure,e2e-traffic} has studied the use of an
+implementation of these intersection attacks called ``Statistical
+Disclosure,'' where an attacker compares network behavior when Alice has sent
+to network when she is absent in order to link an {\it anonymous} sender
+Alice to her regular
+recipients $\mbox{Bob}_1 ...  \mbox{Bob}_N$.   Against {\it pseudonymous}
+recipients, however, these attacks are significantly easier: in the anonymity
+case we assume that many senders may send to any given recipient
+$\mbox{Bob}_i$, but with pseudonymous delivery, we only one
+user sends or receives messages for a given pseudonym.  This additional
+linkability makes the attack converge more quickly.
+
+To examine this effect, we ran a modified version of the attack simulations
+described in~\cite{e2e-traffic}, assuming a single target pseudonym and $N$
+non-target pseudonyms providing cover.  In order to make the attacker's job
+as difficult as possible (and thus establish an upper bound for security), we
+assume that all users behave identically: they receive messages with equal
+probability according to independent geometric distributions in each unit of
+time (receiving no messages with probability $1-P_M$); they each use
+identical reply blocks with path length $\ell$ through mixes in a steady
+state that delay each message each round with probability $P_D$.
+
+We ran the simulated attack with different values for $P_M$, $P_D$, and
+$\ell$, against a nym server with $N=2^{16}$ active pseudonymous users.
+(This is probably an overestimate of the number of users on typical nymserver
+today~\cite{nym-alias-net}.)   We performed 100 trials for each set of
+paramaters.  In the worst case (for the nym holder), when
+$P_M=0.5, \ell=1, P_D=0.1$, the lack of
+mix-net delay variance allowed the simulated
+attacker to guess the user's identity correctly after the user received an
+average of only 37 messages.  In the best simulated case ($P_M=0.5,
+P_D=0.9,\ell=4$), the user was able to receive an average of only 1775
+messages before the attacker guessed correctly.  For an active user, this is
+well within a month's expected traffic.
+
+Although there are various proposals to use dummy traffic to resist
+statistical disclosure attacks, these difficult to implement perfectly in
+practice (due to outages and so forth) and even slight imperfections render
+users vulnerable to attack~\cite{e2e-traffic}.
+
+\subsection{Other security concerns}
+\label{subsec:other-sec}
+
+The information used for authentication of the system components (such as
+the certificates and the hash tree root and metaindex) must be published
+widely to prevent either the collator or any of the distributors from
+attacking clients by tricking them into thinking that the hash root of the
+tree is something other than what all of the other clients know it to be.
+Distributors should do basic sanity checks, such as verifying tree
+integrity. The distributors should also send audit messages of their own
+to verify that the messages correctly appear in the system. Finally,
+clients should make sure that each of the distributors they use agree
+about the value of the hash root.
 
 \section{Performance, Scalability and Optimizations}
 \label{sec:performance}

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