[freehaven-cvs] talk about reputations; talk about mixminion; conclude

[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:
talk about reputations; talk about mixminion; conclude


Index: sync-batching.tex
===================================================================
RCS file: /home/freehaven/cvsroot/doc/sync-batching/sync-batching.tex,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -d -r1.30 -r1.31
--- sync-batching.tex	23 Jan 2004 22:52:22 -0000	1.30
+++ sync-batching.tex	23 Jan 2004 23:26:31 -0000	1.31
@@ -509,6 +509,26 @@
 % reduce entropy in scenarios with low adversary density, because he
 % knows she doesn't exit from her entry node. Hm. -RD
 
+\subsection{Reputations and Node Preferences}
+
+Most deployed systems let users choose a preferred entry or exit hop,
+e.g.~based on trust. A skewed distribution of messages only at the entry
+or exit of the network should not impact entropy too much---we see from
+Figures \ref{fig:caschops}-\ref{fig:freehops} that much of each network's
+entropy is achieved after just a few hops.
+
+Reputation systems, on the other hand, encourage users to preferentially
+choose nodes \emph{throughout} the network. Further, reputation
+information can be exploited by an adversary to reduce anonymity,
+for example by predicting the user's behavior based on reputation
+statistics, or by attracting more traffic by building a strong reputation
+or degrading the reputation of others. One approach to working within
+these constraints would be to put like-reputationed nodes in the same
+layer of the stratified network, or in the same row of the cascade
+network \cite{casc-rep}, so reputation distribution (at each hop or
+in each cascade, respectively) will be more uniform. We leave this
+investigation to future work.
+
 \subsection{Average Entropy vs Actual Entropy}
 \label{subsec:average-actual}
 
@@ -843,36 +863,30 @@
 late message still arrives. in this system, a late message is lost.
 this is not very convenient for the user.
 
-\section{Extensions and Future Work}
-\label{sec:conclusion}
+\section{Comparison with Asynchronous Batching Designs}
 
-In practice, several considerations have to be balanced when choosing
-a batching strategy and network structure. These include maximizing
-anonymity sets (both batch sizes through each node and the overall
-anonymity sets of users); bandwidth considerations; reliability;
-enabling users to choose nodes that they trust; and interactions with
-the reputation system.
+The next step is to begin comparing synchronous free-routes with the
+more traditional asynchronous free-routes, with the goal of presenting
+a plausible design for a realistic protocol that could provide more
+security 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, our design is less robust to
+transient failures (dropped messages are bad for usability), and because
+the pool batching strategy spreads out the probability distributions,
+our design may fall more quickly to long-term statistical disclosure
+attacks~\cite{statistical-disclosure}.
 
-Further analysis of the trade-offs will be needed before choosing a
-final network structure. Note that a planned structure, where each
-users' software follows the plan consistently when constructing
-routes, will generally be able to achieve stronger and more easily
-analysed security properties than less constrained approaches.
+\section{Summary}
+\label{sec:conclusion}
 
-Comparison to Mixminion: No need for a replay cache. But less robust to
-transient failures.
+Previously, only cascade networks were considered secure against very
+powerful adversaries~\cite{disad-free-routes}. In this paper we show that
+other topologies can use the synchronous batching strategy to achieve
+similar protection. Further, we show that free-route topologies with
+synchronous batching compare favorably to cascade networks. We invite
+further analysis of the trade-offs between each topology.
 
-Reputations and node preference
-Most deployed systems let users choose their preferred entry or exit
-hops, e.g.~based on trust. which will mess with our distribution. but
-this is ok because after just a few hops of mixing, the distribution of
-the incoming batch doesn't matter as much anymore.
-Reputation systems \`{a} la mix-acc and casc-rep make people prefer one node
-over another, \emph{throughout} the mix network, not just at entries or
-exits. but we have to tolerate this sort of thing. one approach would
-be to put like-reputationed nodes in the same column of the SA or in
-the same row of the cascade \cite{casc-rep}, so distribution (at each
-hop or in each cascade, respectively) will be more uniform.
 
 
 \section*{Acknowledgements}

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