[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[freehaven-cvs] folding in andrei"s fixes



Update of /home/freehaven/cvsroot/doc/batching-taxonomy
In directory moria.seul.org:/home/arma/work/freehaven/doc/batching-taxonomy

Modified Files:
	taxonomy.tex 
Log Message:
folding in andrei's fixes



Index: taxonomy.tex
===================================================================
RCS file: /home/freehaven/cvsroot/doc/batching-taxonomy/taxonomy.tex,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -d -r1.6 -r1.7
--- taxonomy.tex	7 May 2002 13:24:33 -0000	1.6
+++ taxonomy.tex	8 May 2002 00:00:58 -0000	1.7
@@ -1,4 +1,3 @@
-
 \documentclass{llncs}
 \usepackage{psfrag}
 \usepackage{url}
@@ -141,8 +140,8 @@
 allow the attacker to determine, for instance, the recipient of a
 particular message originating from a sender.  We illustrate this in
 the case of a single threshold mix\footnote{The same attack can be
-used against a mix cascade by mounting it against the first mix,
-or against a mix network by repeating it $l$ (the number of mixes in the
+used against a mix cascade by mounting it against the first mix, or
+against a mix network by repeating it $l$ (the number of mixes in the
 route of the message) times.}.  The attack, commonly referred to as
 the $n-1$ attack, proceeds as follows: The attacker observes the
 target message leaving the sender heading towards the mix and delays
@@ -183,7 +182,7 @@
 
 \item If the attacker can always reduce the anonymity of a message to
 $0$, but may need to spend an arbitrary amount of resources
-(time/messages) to do so,the mix is vulnerable to exact, uncertain
+(time/messages) to do so, the mix is vulnerable to exact, uncertain
 attacks.
 
 \item If the attacker is always able to reduce the anonymity of a
@@ -204,11 +203,10 @@
 Note that Mix 1 is vulnerable only to non-exact blending attacks,
 while the Mix 2 is vulnerable to exact certain attacks.
 
-We now analyze and categorize several mixes. We
-suggest their blending attack cost functions (both of time and space)
-where necessary.  We also look at SG mixes \cite{Kesdogan98}, an
-approach specifically designed to protect against active attacks, in
-section \ref{SG}.
+We now analyze and categorize several mixes. We suggest their blending
+attack cost functions (both of time and space) where necessary.  We
+also look at SG mixes \cite{Kesdogan98}, an approach specifically
+designed to protect against active attacks, in section \ref{SG}.
 
 %Actual cost functions are a massive pain because it is unclear quite
 %what the optimal attack is, say, ``given 500 messages''. On the other
@@ -259,7 +257,7 @@
 \paragraph*{Flushing Algorithm:} 
 When the mix collects $n$ messages, it flushes.
 
-\paragraph*{Mesage Delay:} 
+\paragraph*{Message Delay:} 
 The minimum delay is $\epsilon$ (the message arrives when there are
 $n-1$ messages already in the mix). The maximum delay can be
 infinite (when a message arrives to a mix and no more ever
@@ -303,7 +301,7 @@
 he is able to compromise anonymity of any
 message).
 
-(AAS comment: Verification comments should go here!)
+%(AAS comment: Verification comments should go here!)
 \subsection{Timed Mix}
 
 \paragraph*{Parameters:} 
@@ -384,11 +382,10 @@
 \paragraph*{Blending Attack Behaviour:} 
 This design gives the worst case of threshold and timed mixes (and
 thus still exact and certain). The adversary can choose to perform a
-trickle attack, a flood attack, or a mixture of the two depending
-on whether
-he prefers to wait or send messages.  It can be performed in a minimum
-of $0$ messages in somewhere between $0$ and $2t-\epsilon$ seconds or
-with a maximum of $2(n-1)$ messages, in $\epsilon$ seconds.
+trickle attack, a flood attack, or a mixture of the two depending on
+whether he prefers to wait or send messages.  It can be performed in a
+minimum of $0$ messages in somewhere between $0$ and $2t-\epsilon$
+seconds or with a maximum of $2(n-1)$ messages, in $\epsilon$ seconds.
 
 \paragraph*{Adversaries}
 This attack can be performed by either the global inserting or the
@@ -415,7 +412,7 @@
 The $n-1$ attack is still exact and uses a combination of the
 attacks on the threshold and the timed mixes. It takes a maximum of
 $2t-\epsilon$ and a minimum of $\epsilon$ seconds, a maximum of
-$2(n-1)$ and a minimum of $(n-1)$ messages.
+$2(n-1)$ and a minimum of $n-1$ messages.
 
 \paragraph{Adversaries}
 It is clear that to mount an attack on this mix, the attacker has to
@@ -519,27 +516,27 @@
 The concept of minimum anonymity in pool mixes is slightly more
 elusive. In the threshold mix case we assumed that all the messages in
 the batch come from different senders. So, regardless of previous
-senders, the minimum anonymity of a threshold pool mix
-is at least $n$, and therefore no worse than that of a corresponding
-threshold mix.  We could assume that all the other messages may have
-come from the same sender and thus provide no anonymity, but
-this would be overly pessimistic -- the entire history of the mix is
-unlikely to consist of messages from just one sender.
+senders, the minimum anonymity of a threshold pool mix is at least
+$n$, and therefore no worse than that of a corresponding threshold
+mix.  We could assume that all the other messages may have come from
+the same sender and thus provide no anonymity, but this would be
+overly pessimistic -- the entire history of the mix is unlikely to
+consist of messages from just one sender.
 
 \paragraph*{Blending Attack Behaviour:} 
-In general, the blending attack has two phases:
-flushing the mix so that no good messages remain inside it, then
-forwarding in the target message and flushing it out onto the
-network. In the past, the whole attack used two mix flushes. With pools,
-two flushes are no longer sufficient.
-Furthermore, there is now a small but
-non-zero probability that a given message (e.g. the target
-message) remains in the mix for an arbitrary length of time.
-Intuitively, the attack ceases to be certain. It proceeds as follows:
+In general, the blending attack has two phases: flushing the mix so
+that no good messages remain inside it, then forwarding in the target
+message and flushing it out onto the network. In the past, the whole
+attack used two mix flushes. With pools, two flushes are no longer
+sufficient.  Furthermore, there is now a small but non-zero
+probability that a given message (e.g. the target message) remains in
+the mix for an arbitrary length of time.  Intuitively, the attack
+ceases to be certain. It proceeds as follows:
 
 The attacker delays the target message, fills up the pool mix and
 flushes it. If $j$ of the attacker messages don't come out, he knows that
 % critical fix -- i added a "don't". true? -RRD
+% True. Sorry. AAS.
 $f-j$ good messages remain inside the pool mix. He now delays all
 the other incoming good messages and tries to flush them out of the
 mix (he can detect all good messages coming out). Of course, this
@@ -590,22 +587,22 @@
 
 \subsection{Timed Pool Mix}
 
-\paragraph*{Parameters:} $t$, period; $f$, pool; ($f$, threshold).
+\paragraph*{Parameters:} $t$, period; $f$, pool; ($0$, threshold).
 
 \paragraph*{Flushing Algorithm:} 
 The mix is flushed every $t$ seconds. A pool of $f$ messages chosen
 uniformly at random is retained in the mix. The others are forwarded
 on. If fewer then $f$ messages are in the mix, it does not fire.
 (Thus, strictly speaking, this is a threshold and timed pool mix, for
-which the threshold is $f$.)
+which the threshold is $0$.)
 
 \paragraph*{Message Delay:} 
 The minimum message delay is $\epsilon$, and there is no maximum delay
-(if no messages arrive, the messages that are in the pool will
-never leave the mix). Like in the case of the threshold pool mix, there
-is again a small but non-zero probability
-that any given message could remain in the mix for an arbitrarily
-long time even if there are messages flowing through the mix.
+(if no messages arrive, the messages that are in the pool will never
+leave the mix). Like in the case of the threshold pool mix, there is
+again a small but non-zero probability that any given message could
+remain in the mix for an arbitrarily long time even if there are
+messages flowing through the mix.
 
 
 \paragraph*{Anonymity:}
@@ -613,26 +610,26 @@
 limited by the memory capacity of the mix) of messages to be mixed
 together.  If we assume a constant rate $r$ of message arrival, the
 anonymity provided by this mix can be calculated in just the same way
-as for the threshold case; but we leave this calculation for future work.
+as for the threshold case; but we leave this calculation for future
+work.
 
 Alternatively, the anonymity of a message going through this mix can
-be calculated from the history of the mix --- a record of the operation
-of the mix ever since it was started. Like in the threshold case, a
-mix's history includes the senders of each message and also the number
-of messages that got mixed together in each batch (and, potentially,
-a whole host of
-other features). Of course, in practice, a record of the only last few
-rounds gives a good approximation.
+be calculated from the history of the mix --- a record of the
+operation of the mix ever since it was started. Like in the threshold
+case, a mix's history includes the senders of each message and also
+the number of messages that got mixed together in each batch (and,
+potentially, a whole host of other features). Of course, in practice,
+a record of the only last few rounds gives a good approximation.
 
-Assuming a threshold pool mix has a threshold larger
-than the pool size, the minimum anonymity of a timed pool mix is
-clearly smaller than that for the threshold pool mix. We note that in
-pool mixes the bulk of the anonymity comes from mixing the target message
-with the batch of incoming messages, not from
-mixing it with the messages in the pool. Because the timed mix does
-not always have this batch of messages for mixing the target message,
-its minimum anonymity should be considered to be very much
-worse than that of the threshold pool mix.
+Assuming a threshold pool mix has a threshold larger than the pool
+size, the minimum anonymity of a timed pool mix is clearly smaller
+than that for the threshold pool mix. We note that in pool mixes the
+bulk of the anonymity comes from mixing the target message with the
+batch of incoming messages, not from mixing it with the messages in
+the pool. Because the timed mix does not always have this batch of
+messages for mixing the target message, its minimum anonymity should
+be considered to be very much worse than that of the threshold pool
+mix.
 
 \paragraph*{Blending Attack Behaviour:}
 Two flavours of blending attack are possible on this mix.
@@ -640,36 +637,36 @@
 add many or just a few messages to each flush. (He prevents all
 other messages from reaching the mix).
 
-By adding as many messages as possible in one round, he maximizes
-the probability that after one flush
-only the attacker messages will be left in the pool. He knows
-that he has succeeded if $f$ of his messages do not come out with the
-flush. This approach is very inefficient in terms of the
-number of messages added by the attacker ($b$) since the probability of
-flushing the mix by this method is $\frac{f^2}{b+f}$ (supposing there
-were $f$ good messages in the mix initially).\footnote{As previously
-  mentioned, in practice there is an upper limit on $b$ due to the
-  finite memory capacity of the mix.}  However, this aims to flush the
-good messages out of the mix in one round, and therefore a maximum of
-$t$ seconds. Thus the entire attack can be executed in less than
-$2t$ seconds with an arbitrarily high probability of success.
+By adding as many messages as possible in one round, he maximizes the
+probability that after one flush only the attacker messages will be
+left in the pool. He knows that he has succeeded if $f$ of his
+messages do not come out with the flush. This approach is very
+inefficient in terms of the number of messages added by the attacker
+($b$) since the probability of flushing the mix by this method is
+$\frac{f^2}{b+f}$ (supposing there were $f$ good messages in the mix
+initially).\footnote{As previously mentioned, in practice there is an
+upper limit on $b$ due to the finite memory capacity of the mix.}
+However, this aims to flush the good messages out of the mix in one
+round, and therefore a maximum of $t$ seconds. Thus the entire attack
+can be executed in less than $2t$ seconds with an arbitrarily high
+probability of success.
 
-Alternatively, the attacker can add just one message to each round
-for many rounds. This is very efficient in the number of
-messages $b$ (indeed, this attack is much more efficient than
-the one on the threshold pool mix in terms of messages, but clearly
-not in terms of time). The probability of flushing the mix is
-$f\left(\frac{f}{f+1}\right)^b$, but this approach delays all the messages
-to the
-mix by $tb$ seconds, which is highly observable to the users of the
-anonymity system.
+Alternatively, the attacker can add just one message to each round for
+many rounds. This is very efficient in the number of messages $b$
+(indeed, this attack is much more efficient than the one on the
+threshold pool mix in terms of messages, but clearly not in terms of
+time). The probability of flushing the mix is
+$f\left(\frac{f}{f+1}\right)^b$, but this approach delays all the
+messages to the mix by $tb$ seconds, which is highly observable to the
+users of the anonymity system.
 
 The attacker can choose either or a combination of these approaches,
 based on whether he can send out many messages or delay messages to a
 mix for a long time.
 
 \subsection{Cottrell Mix (Timed Dynamic-Pool Mix)} 
-\paragraph*{Parameters:} $t$, period; $min$, pool; $frac$, fraction; ($min$ threshold).
+\paragraph*{Parameters:} 
+$t$, period; $min$, pool; $frac$, fraction; ($0$ threshold).
 
 \paragraph*{Flushing Algorithm:} 
 The mix gets flushed every $t$ seconds.  A fraction $frac$ of randomly
@@ -684,6 +681,8 @@
 This mix has been used in the Mixmaster remailer system for a number of
 years, but has not been described or evaluated before.
 
+%Good, thank you for that!
+
 \paragraph*{Message Delay:} Like the other pool mixes, the
 minimum delay is $\epsilon$ and there is no upper limit on the delay.
 The mean delay depends on the future rate of arrival of messages into
@@ -692,15 +691,14 @@
 This is in general higher than that of the timed pool mix.
 
 \paragraph*{Anonymity:}
-The Cottrell mix has identical minimum and maximum anonymity properties
-compared to a timed pool mix. We could similarly use
-a log of the mix's activity
-to calculate the anonymity of a message passing through it
-(although the calculation would be slightly different).  Also, we
-note that the anonymity provided by the mix would be higher than that
-provided by a timed mix (as the number of messages in the mix goes up,
-$frac$ keeps the chance of the message remaining in the mix constant,
-whereas it decreases in the case of the timed pool mix).
+The Cottrell mix has identical minimum and maximum anonymity
+properties compared to a timed pool mix. We could similarly use a log
+of the mix's activity to calculate the anonymity of a message passing
+through it (although the calculation would be slightly different).
+Also, we note that the anonymity provided by the mix would be higher
+than that provided by a timed mix (as the number of messages in the
+mix goes up, $frac$ keeps the chance of the message remaining in the
+mix constant, whereas it decreases in the case of the timed pool mix).
 
 \paragraph*{Blending Attack Behaviour:}
 The introduction of the dynamic parameter $frac$ has several
@@ -708,23 +706,31 @@
 
 Firstly, the maximum probability of flushing the mix of good messages
 in one flush is $frac$. Therefore there is no possibility of flushing
-the mix with high probability in one flush: the first of the two blending
-attacks on timed pool mixes is blocked.
+the mix with high probability in one flush: the first of the two
+blending attacks on timed pool mixes is blocked.
 
 Secondly, the attacker has to find out how many messages are in the
 mix.  Of course, the number of good messages in the mix is easy to
 calculate from the number of messages that come out. 
+
 %FIXME can you elaborate more on this, andrei?
+%Not worth putting in, IMO but:
+%We can either use the number of messages the attacker put in, the
+%number that came out and, knowing frac, work out the number of good
+%messages remaining %(trivial, think about it!) 
+%or just let the mix alone for a while until it outputs nothing 
+%in which case $min$ messages remain. 
+%
 
-Finally, the number of messages inside the pool mix may be
-arbitrarily high and cannot be reduced to below $min$ in one round.
-Therefore, if we wish to send a message 
+Finally, the number of messages inside the pool mix may be arbitrarily
+high and cannot be reduced to below $min$ in one round.  Therefore, if
+we wish to send a message
 %and decrease the probability of it
 %getting tracked,
-that is harder to track,
-we should send it at the time of higher traffic ---
-thereby increasing the cost (in terms of messages or time) of attempted
-attacks on it%\footnote{At times of high traffic, the mix will contain
+that is harder to track, we should send it at the time of higher
+traffic --- thereby increasing the cost (in terms of messages or time)
+of attempted attacks on it
+%\footnote{At times of high traffic, the mix will contain
 %many more messages than $min$, and to flush it free of good messages
 %will require either more time or more messages from the attacker.}.
 %
@@ -737,11 +743,17 @@
 the traffic to the mix for a substantial number of rounds, and
 therefore for a substantial time.
 
-%\begin{exa}
-%Example demonstrating above
-%\end{exa}
+\begin{exa}
+A Cottrell mix with a pool of 60 messages and fraction of
+$\frac{6}{10}$ requires 5 rounds for the expected number of good
+messages remaining in the mix to fall below 1. If the period is 5
+minutes, the overall flushing time is 25 mins. 500 messages will be
+used in the flushing part of the attack. 
+\end{exa}
 
 %FIXME Andrei, you should actually write the example :)
+% I think this is enough. If you think more is required, either fill
+% in or kill it.
 
 This example shows that the protection this mix provides against
 blending attacks is still weak.  Indeed, the probability of a
@@ -802,17 +814,18 @@
 attack significantly (if at all). Thus, we shall not pursue it
 further.  
 
-\subsection{But resisting blending can prevent verification!}
+\subsection{Resisting blending vs verification}
 
 The tools that we give honest mixes to protect against these blending
-attacks are precisely the tools that dishonest MIXes use to launch
-them. \emph{Uncertainty} comes from not letting observers know when
-a given message might leave the mix; \emph{inexactness} comes from
-not letting observers know how many messages are currently inside the
-mix. This flexibility allows a mix to prevent the adversary from learning
-the details of message flow, but at the same time it allows a compromised
-mix to manipulate message flow, for example by delaying a message until
-it's ready to launch a trickle attack on the downstream hop.
+attacks are precisely the tools that dishonest mixes use to launch
+them. \emph{Uncertainty} comes from not letting observers know when a
+given message might leave the mix; \emph{inexactness} comes from not
+letting observers know how many messages are currently inside the
+mix. This flexibility allows a mix to prevent the adversary from
+learning the details of message flow, but at the same time it allows a
+compromised mix to manipulate message flow, for example by delaying a
+message until it's ready to launch a trickle attack on the downstream
+hop.
 
 Many basic mix verification schemes, such as that proposed in
 \cite{chaum81untraceable} where senders observe the batches exiting
@@ -825,21 +838,21 @@
 the allowed timeframe. All of these systems are designed to ensure that
 messages will leave each mix predictably.
 
-In some topologies, such as free-route mix-nets, a widespread delaying
-attack is difficult to perform because the adversary must control all
-mixes that are sending messages to the target mix. In this case we may
-gain more by allowing mixes to protect against blending attacks than we
-lose by permitting compromised nodes to manipulate messages. At the other
-extreme, in a cascade topology, a single compromised mix has absolute
-control over the downstream message batch. In this case verification of
-correct processing is critical, to prevent wholescale (unobservable!)
-anonymity compromise. Methods to detect an attack afterwards, e.g. by
-checking for successful delivery of test messages at the end of the
-cascade \cite{casc-rep}, can help detect misbehaving mixes --- but they
-still allow the adversary to uncover a few messages before he's noticed.
-As we design new protocols and batching approaches, we must consider
-this tradeoff between protection from blending attacks and protection
-from verifiability.
+In some topologies, such as free route mix networks, a widespread
+delaying attack is difficult to perform because the adversary must
+control all mixes that are sending messages to the target mix. In this
+case we may gain more by allowing mixes to protect against blending
+attacks than we lose by permitting compromised nodes to manipulate
+messages. At the other extreme, in a cascade topology, a single
+compromised mix has absolute control over the downstream message
+batch. In this case verification of correct processing is critical, to
+prevent wholescale (unobservable!)  anonymity compromise. Methods to
+detect an attack afterwards, e.g. by checking for successful delivery
+of test messages at the end of the cascade \cite{casc-rep}, can help
+detect misbehaving mixes --- but they still allow the adversary to
+uncover a few messages before he has noticed.  As we design new
+protocols and batching approaches, we must consider this tradeoff
+between protection from blending attacks and verifiability.
 
 \subsection{Cover Traffic}
 
@@ -847,36 +860,36 @@
 traffic. Indeed, in designing the Mixmaster system \cite{Cott94},
 Cottrell realised that even the timed dynamic pool mixes still leave
 the system vulnerable to attacks. He decided to introduce
-cover traffic to improve attack-resistance.
+cover traffic to improve attack resistance.
 
 At the moment, Mixmaster has the following cover traffic policy: at
 each flush one dummy is put out onto the network. The dummy message 
 generated by the mix looks like a normal message, but has a constant
 length of 5 hops and ends at a mix rather than at a receiver.
 % Have you confirmed it uses 5? Where is this from? -RRD
-
-Note that this dummy policy still allows an attacker to flush the
-mix free of good messages and be certain about it.  However, once the
-good message is inserted into the mix, at every round at least one
-good message comes out. Naturally, when two messages come out, the
-attacker knows that the target message was one of those, but he does
-not know which one. If the attacker finishes here, he has reduced the
-anonymity of the message to $1$ (that is, two possible receivers). However,
-he can do better. Because Mixmaster is a mix network, he can keep
+% AAS: Lance.
+Note that this dummy policy still allows an attacker to flush the mix
+free of good messages and be certain about it.  However, once the good
+message is inserted into the mix, at every round at least one good
+message comes out. Naturally, when two messages come out, the attacker
+knows that the target message was one of those, but he does not know
+which one. If the attacker finishes here, he has reduced the anonymity
+of the message to $1$ (that is, two possible receivers). However, he
+can do better. Because Mixmaster is a mix network, he can keep
 tracking both messages (and all the messages that result when these
 pass through more mixes) until he can detect that one message has gone
-to a recipient. That is the target message since all the dummy messages
-end in a mix. This attack is exact, but much more expensive than
-anything we have described previously. The situation can be further
-improved by making the mix choose its route length for the dummies
-from a uniform distribution rather than always choosing $5$. We could
-get further protection by allowing mixes to send cover traffic to
-the users (possibly in some format that can be automatically discarded).
-However, providing complete protection with this approach is very
-hard. Each mix must know all the users in the system: if a mix only
-delivers dummies to a subset of the users, an adversary can distinguish
-with better than even probability between a dummy and a legitimate
-message.
+to a recipient. That is the target message since all the dummy
+messages end in a mix. This attack is exact, but much more expensive
+than anything we have described previously. The situation can be
+further improved by making the mix choose its route length for the
+dummies from a uniform distribution rather than always choosing
+$5$. We could get further protection by allowing mixes to send cover
+traffic to the users (possibly in some format that can be
+automatically discarded).  However, providing complete protection with
+this approach is very hard. Each mix must know all the users in the
+system: if a mix only delivers dummies to a subset of the users, an
+adversary can distinguish with better than even probability between a
+dummy and a legitimate message.
 
 %if a mix doesn't
 %know about even a single user when it generates a dummy, an adversary
@@ -907,8 +920,7 @@
 blending attacks; we leave its analysis for future work.
 
 
-\section{Related work: stop and go mixes}
-% this is fishy. the related work section has only one related work? -RRD
+\section{Related Work}
 \label{SG}
 
 While active attacks have been widely cited in the literature and
@@ -939,21 +951,20 @@
 discarded. Therefore the attacker's ability to delay messages is much
 more limited, so active attacks are harder.
 
-The attack is uncertain, the authors argue that the
-probability of executing the attack successfully is very low. 
+The attack is uncertain, the authors argue that the probability of
+executing the attack successfully is very low.
 
 However, the scheme relies on the users being able to accurately
 calculate a security parameter that depends on their estimate of the
 rate of arrival of messages to the mixes that the target message will
 go through \emph{at the time it will travel through them}. In other
 words, the users need to be able to predict the traffic levels in the
-system in the future to remain anonymous. This weakness
-is likely to be exploited by the attacker (the exact
-details depend, of course, on how the security parameter is
-calculated). Further, an attacker able to insert arbitrary messages
-into the system will still be able to arbitrarily affect the input
-batch with which a target message enters any mix, regardless of the
-timing requirements of that message.
+system in the future to remain anonymous. This weakness is likely to
+be exploited by the attacker (the exact details depend, of course, on
+how the security parameter is calculated). Further, an attacker able
+to insert arbitrary messages into the system will still be able to
+arbitrarily affect the input batch with which a target message enters
+any mix, regardless of the timing requirements of that message.
 
 Thus, we defer the evaluation of SG mixes to future work as the
 precise details of parts of the protocol crucial to the security of
@@ -963,16 +974,17 @@
 In this paper we have presented a set of mixes and examined their
 anonymity, message delay and blending attack properties. In
 particular, we suggested that it is useful to partition the mixes into
-certain categories of vulnerability but emphasized that the cost
-and worst case attack scenario are important qualities to consider.
+certain categories of vulnerability but emphasized that the cost and
+worst case attack scenario are important qualities to consider.
 
 Although we have shown the mixes to be rather vulnerable to active
-attacks, some avenues still have hope. The first
-of these is verification schemes.
+attacks, some avenues still have hope. The first of these is
+verification schemes.
 
 The second and the more widely used solution is cover traffic. Here we
-assess the cover traffic policy used in Mixmaster, point out weaknesses,
-and discuss some approaches to strengthening its dummy policy.
+assess the cover traffic policy used in Mixmaster, point out
+weaknesses, and discuss some approaches to strengthening its dummy
+policy.
 
 The paper can also be treated as a tutorial on the different styles of
 mixes and as a recommendation to the Mixmaster implementors to alter
@@ -981,4 +993,5 @@
 \bibliography{taxonomy}
 
 \end{document}
+
 

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