[freehaven-cvs] merge back in the other stuff. did i miss anything, ...

[arma@xxxxxxxx]

Update of /home/freehaven/cvsroot/doc/alpha-mixing
In directory moria:/home/arma/work/freehaven/doc/alpha-mixing

Modified Files:
	alpha-mixing.tex 
Log Message:
merge back in the other stuff. did i miss anything, paul?


Index: alpha-mixing.tex
===================================================================
RCS file: /home/freehaven/cvsroot/doc/alpha-mixing/alpha-mixing.tex,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -d -r1.19 -r1.20
--- alpha-mixing.tex	11 Mar 2006 00:31:12 -0000	1.19
+++ alpha-mixing.tex	11 Mar 2006 00:35:49 -0000	1.20
@@ -209,7 +209,7 @@
 message entering the mix, e.g., that this is provided to the mix
 encrypted together with the message. However we do allow that the
 adversary might know the strategy by which alpha was chosen; we
-examine this issue further in Section~\ref{attacker-knowledge}. What
+examine this issue further in Section~\ref{sec:attacker-knowledge}. What
 should that strategy be? It would seem that choosing higher alphas
 would correspond to greater anonymity for messages. We now make this
 more precise.
@@ -401,10 +401,11 @@
 
 where $Q(n,k)$ denotes the number of ways of partitioning $n$ into
 exactly $k$ distinct parts. Generating values from such a distribution
-is possible, for instance, using the algorithm described in
-\cite{devroye86}. This seems to deal with the first problem (the
+is possible, for instance, using the algorithm described in~\cite{devroye86}.
+This seems to deal with the first problem (the
 analysis to show this is beyond the scope of this paper). For the
-second part, we need to decide whether the sender cares
+second part,it depends what the sender wants to protect:
+does she care
 about having an estimate of the security parameter
 associated with just herself, with herself and the recipient,
 or just the recipient. Note that if the first and
@@ -422,7 +423,7 @@
 and hence obtain a sequence of alphas to insert into the message.
 
 If we wish to guarantee that neither the first nor the last mix can
-locally know anything about sensitivity level of a message, we can
+locally know anything the about sensitivity level of a message, we can
 simply stipulate for message $M$ that $\alpha^{(0)}_{M,0} =
 \alpha^{(n)}_{M,0} = 0$ (for a path length of $n+1$. Similarly we
 could stipulate that $\alpha^{(1)}_{M,0} = \alpha^{(n-1)}_{M,0} \leq
@@ -577,7 +578,14 @@
 These use a dynamic batching strategy in which messages are chosen
 for the current batch randomly by the mix from a collective pool
 while alpha mixing is based on individual choices made by the sender.
-We now turn to how to combine these features.
+
+We now turn to various generalizations on the basic deterministic-alpha
+mix design, including ways to combine these features.
+
+\section{Beta Alpha: Variations on Alpha Mixing}
+\label{sec:beta-alpha}
+
+\subsection{Preventing end-to-end timing on alpha mixnets}
 
 \section{Dynamic-Alpha Mixing and Other Variations}
 \label{sec:dynamic-alpha}
@@ -613,6 +621,7 @@
 necessarily including $0$). This would (1) prevent such an attack if
 the adversary cannot predict her distribution, (2) still have as much
 predictability on delivery time as stop-and-go mixes, and (3) unlike
+
 stop-and-go, still allow eventual delivery of all messages not
 completely blocked. We are not primarily focused in this paper
 on end-to-end timing attacks, and we will say no more about them.
@@ -641,7 +650,7 @@
 once. This will prevent an adversary from learning the sensitivity of
 messages by observing their alpha levels from their positions in the
 batch. This together with minimal dummy scheme presented in
-Section~\ref{dummies} would substantially reduce the effect of
+Section~\ref{sec:dummies} would substantially reduce the effect of
 blending: an adversary emptying the mix of all messages up to the
 highest reasonably expected level, trickling in a message then
 flooding with $\alpha_0 = 0$ messages repeatedly to learn the

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