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

[freehaven-cvs] slightly better. good enough for draft.



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:
slightly better. good enough for draft.


Index: taxonomy.tex
===================================================================
RCS file: /home/freehaven/cvsroot/doc/batching-taxonomy/taxonomy.tex,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -d -r1.21 -r1.22
--- taxonomy.tex	31 Aug 2002 10:23:24 -0000	1.21
+++ taxonomy.tex	2 Sep 2002 07:55:46 -0000	1.22
@@ -291,12 +291,7 @@
 this is not necessarily so. If the global inserting attacker is able
 to insert $n-1$ of his own messages between each of the ``good''
 messages going into a mix, he effectively mounts an $n-1$ attack on
-each of them.\footnote{In fact, in theory only insertion of messages
-is necessary, assuming there are predictable bounds on network link
-capacities, and that it is never necessary to cause a reordering of
-legitimate messages.  However, it is more realistic to model attacks
-as a combination of delays and insertions, and we will not pursue this
-potential reduction.}
+each of them.
 
 Another possible attack scenario is when an attacker owns a mix in a
 free route mix network. He has the capability to delay all the
@@ -364,8 +359,10 @@
 
 \paragraph*{Adversaries:}
 This attack does not require any insertion of messages, so the global
-delaying attacker is sufficient.\footnote{However, as previously
-  noted, the delays could be caused by insertions.}  We also note that
+delaying attacker is sufficient.
+%\footnote{However, as previously
+%  noted, the delays could be caused by insertions.}
+We also note that
 this ``attack'' can happen naturally in low traffic conditions, so a
 dishonest mix may be able to attack the next hop of a message simply
 by holding it until the next hop is empty and about to fire.
@@ -464,13 +461,12 @@
 \subsection{Threshold Pool Mix}
 
 \paragraph*{Parameters:} $n$, threshold; $f$, pool.
-% why did we choose the variable $f$? -RRD
 
 \paragraph*{Flushing Algorithm:} 
 The mix fires when $n+f$ messages accumulate in the mix. A pool of $f$
 messages (chosen uniformly at random from all the messages) is
-retained in the mix. (This can be thought of as the feedback into the
-mix, hence the variable name.) The other $n$ are forwarded on. Note
+retained in the mix. (Consider these messages as feedback into the
+mix.) The other $n$ are forwarded on. Note
 that the threshold is the threshold of messages that must be received
 to fire again during ongoing operation. For pool mixes this is
 distinct from the `threshold' of messages to fire when the mix is
@@ -542,12 +538,6 @@
 guaranteed to flush out the mix completely or to flush out the target
 message, the attack is uncertain.
 
-% redundant? removing. -rd
-%Note that this attack crucially depends on the attacker being able to
-%delay messages 
-%%for a some time
-%and/or send messages at very high rates.
-
 \paragraph*{Analysis:} 
 Flushing out the mix: after $r$ rounds, the probability that a
 particular message that was in the mix at round $0$ is still in the
@@ -647,10 +637,7 @@
 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}$ 
-% can we put a more obvious version of this fraction, followed by an
-% equal sign, followed by the above?
-(supposing there were $f$ good messages in the mix
+$\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
@@ -892,9 +879,8 @@
 reputation if it hasn't obtained a receipt from the next hop within
 the allowed timeframe. All of these systems are designed to ensure
 that messages will leave each mix predictably.
-%roger -- remember to integrate this paragraph better
 Yet more verification
-schemes which work in a system with pool mixes are described in
+schemes that work in a system with pool mixes are described in
 \cite{Jer2000,FGJP98}. There the authors propose a commitment scheme
 which ensures that the mix commits to a decision before he receives the
 target message, and his actions are verifiable by the sender of the
@@ -1054,10 +1040,16 @@
 assess the cover traffic policy used in Mixmaster, point out
 weaknesses, and discuss some approaches to strengthening its dummy
 policy.
+% we didn't really talk this much about cover traffic. hrm.
 
 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
 the cover traffic policy and introduce thresholds into the mixes.
+% i don't buy this yet. making the threshold 2 rather than 1 doesn't
+% impact the fact that the pool provides most of the anonymity. so
+% it's only when the threshold approaches the pool size that it starts
+% to matter, and as proposed earlier a message in the pool is 'more
+% useful' than a message in the batch. hrm.
 
 \begin{center}
 \renewcommand{\arraystretch}{1.3}

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