[freehaven-cvs] finish one of the unwritten subsec"s

[arma@seul.org (Roger Dingledine)]

Update of /home/freehaven/cvsroot/doc/sync-batching
In directory moria.mit.edu:/home2/arma/work/freehaven/doc/sync-batching

Modified Files:
	sync-batching.tex 
Log Message:
finish one of the unwritten subsec's


Index: sync-batching.tex
===================================================================
RCS file: /home/freehaven/cvsroot/doc/sync-batching/sync-batching.tex,v
retrieving revision 1.40
retrieving revision 1.41
diff -u -d -r1.40 -r1.41
--- sync-batching.tex	26 Jan 2004 03:55:52 -0000	1.40
+++ sync-batching.tex	26 Jan 2004 04:22:58 -0000	1.41
@@ -404,7 +404,7 @@
 between 20 and 30 active nodes.)
 
 Messages proceed through all of our networks in \emph{layers}; all of the
-nodes in a layer process messages of one mxinet batch at the same time.
+nodes in a layer process messages of one mixnet batch at the same time.
 In general we describe networks as $n$x$\ell$, where $n$ is the number
 of nodes at each layer and $\ell$ is the number of nodes in a path.
 
@@ -883,28 +883,27 @@
 topologies investigated appears to be the free route, and worst is the
 cascade.
 
-\subsection{Robustness in async vs sync}
-
-[This section still draft -RD]
+\subsection{Comparison with Asynchronous Batching Designs}
 
-But there's a deeper issue: in asynchronous-batching designs, a
-late message still arrives. in this system, a late message is lost.
-this is not very convenient for the user.
+We have shown synchronous free-routes can provide good anonymity, but we
+must also begin comparing this design to more traditional asynchronous
+free-route designs like Mixminion. Synchronous batching does away with
+the need for a replay cache (each message is labelled with its batch),
+removes partitioning attacks from key rotation, and generally provides
+clearer anonymity guarantees.
 
-\subsection{Comparison with Asynchronous Batching Designs}
+On the other hand, because Mixminion's pool batching strategy
+spreads out message probability distributions between batches, our
+design may fall more quickly to long-term statistical disclosure
+attacks~\cite{statistical-disclosure}. Our design is also less robust
+to transient failures: a late Mixminion message still arrives, whereas
+in our system a node that is down during $t_\mathrm{hop}$ loses all
+messages going through it. But our design can tell the user for sure
+whether his mail was delivered in the batch (and he can resend if not),
+whereas late messages in Mixminion always leave the user wondering if
+it will come out sometime.
 
-Now that we have shown synchronous free-routes can provide good anonymity,
-we must also begin comparing this design to the more traditional
-asynchronous free-route design, with the goal of presenting a plausible
-design that achieves better anonymity than Mixminion. Synchronous
-batching does away with the need for a replay cache (each message is
-labelled with its batch), removes partitioning attacks from key rotation,
-and generally provides clearer anonymity guarantees. On the other hand,
-because Mixminion's pool batching strategy spreads out message probability
-distributions between batches, our design may fall more quickly to
-long-term statistical disclosure attacks~\cite{statistical-disclosure}. It
-is also less robust to transient failures---dropped messages are bad
-for usability. We leave further comparison to future work.
+We leave further comparison to future work.
 
 \section{Summary}
 \label{sec:conclusion}

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