[freehaven-cvs] play with the conclusion

[arma@seul.org (Roger Dingledine)]

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

Modified Files:
	e2e-traffic.tex 
Log Message:
play with the conclusion


Index: e2e-traffic.tex
===================================================================
RCS file: /home/freehaven/cvsroot/doc/e2e-traffic/e2e-traffic.tex,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -d -r1.31 -r1.32
--- e2e-traffic.tex	25 Jan 2004 12:23:48 -0000	1.31
+++ e2e-traffic.tex	25 Jan 2004 13:38:45 -0000	1.32
@@ -936,81 +936,34 @@
 network.  When most of the network is observed ($\Pobserve>70\%$ in our
 results), the attack is hardly impaired at all.  As more of the network is
 concealed ($.4<\Pobserve<.7$) the attack becomes progressively
-harder. Finally, as as $\Pobserve$ approaches $0$, the required number of
-rounds needed approaches infinity.
+harder. Finally, as $\Pobserve$ approaches $0$, the required number of
+rounds approaches infinity.
 
 %======================================================================
 \section{Conclusions}
 \label{sec:conclusion}
-Our results demonstrate that long-term end-to-end intersection attacks can
-succeed under a variety of complicating factors.  In
-closing, we offer suggestions for mix network designs, and suggest several open
-questions for future work.
-
-\subsubsection{Implications for mix network design:}
-%\label{subsubsec:implications}
-If we were to design a mix network based on our findings here, what steps
-should we take to frustrate intersection attack?
-
-The first lesson is this: {\bf high variability} in message delays is
-essential.  By `spreading' the effects of each incoming message over several
-output rounds, variability in delay increases each message's anonymity set, and
-amplifies the effect of padding.
-
-{\bf Padding} seems to slow traffic analysis, especially as the volume of
-padding approaches the volume of the sender's actual messages,
-drowning out the signal.
-
-Users should be educated about the effects of their chosen {\bf message
-volume}: sending infrequently is safe, especially if the user doesn't
-repeat the same traffic pattern long enough for the attacker to identify
-it. Conversely, sending ``almost always'' is comparatively safe.  But users
-who send messages to the same group of recipients intermittently but
-frequently, over a long period of time, have increased vulnerability to
-intersection attacks.
-
-The threat of non-global observers must not be ignored.  Much threat analysis
-for high-latency mix networks assumes that a passive adversary must watch the
-entire network to threaten senders' anonymity.  We have shown this to be
-false---any attacker who can watch the bulk of the servers Alice chooses as
-entry and exit points can run an intersection attack to learn her recipients.
-Thus, mix networks should take steps to {\bf minimize the number of messages}
-that a limited attacker can see entering and exiting the network.  Possible
-approaches include encouraging users to run their own mixes; choosing
-messages' entry and exit points to cross geographical and organization
-boundaries; and (of course) increasing the number of mixes in the network.
-% We said that fixed entry/exit might help too, but I now think it 
-% wouldn't.  Suppose the attacker observes c nodes out of n.  If I 
-% choose random paths, the attacker sees (c/n)^2 of my traffic with
-% probability 1.  If I choose a fixed entry, the attacker sees c/n
-% of my traffic with probability c/n.  No real difference.
-%
-% In fact, a limited attacker (P_observe=.2) with a diffuse target should
-% _hope_ that people choose fixed entries.  If they do, then he can
-% eventually make the intersection attack work against the ones who use him
-% as their fixed entry.  But if they _don't_ choose fixed entries, he only
-% sees 4% of everyone's traffic, which is not enough to break anybody.
-%
-% Fixed entries are a good idea for low-latency systems, when a single
-% connection with an attacker on each end compromises a sender--receiver
-% link.
+Our results demonstrate that long-term end-to-end intersection attacks
+can succeed under a variety of complicating factors.  In closing, we
+suggest several open questions for future work, and offer recommendations
+for mix network designs.
 
 \subsubsection{Questions for future work:}
 %\label{subsubsec:future-work}
-Many questions remain to be answered before the effectiveness of long-term
+Many questions remain before the effectiveness of long-term
 intersection attacks can be considered a closed problem.
 
 % These need to get re-ordered. -NM
 
 It would be beneficial to find closed-form equations for expected number of
 rounds required to mount these attacks, as Danezis does for statistical
-disclosure \cite{statistical-disclosure}.
+disclosure.
 
 The attacks we have discussed here assume a purely passive adversary, but
 they can easily be generalized to incorporate information gained by an active
-attacker.  Past work on avoiding blending attacks (flooding, trickle, $n-1$)
-has concentrated on preventing an attacker from gaining certain knowledge of
-a Alice's recipients---but in fact, an active attack that only reveals 
+attacker.  Past work on avoiding blending attacks \cite{trickle02}
+% (flooding, trickle, $n-1$)
+has concentrated on preventing an attacker from being certain of
+Alice's recipients---but in fact, an active attack that only reveals 
 slight probabilities about Alice's recipients can provide information
 to speed up the intersection attacks in this paper.
 % also: run a server, knock down nodes, improve linkability, convince Alice
@@ -1028,15 +981,16 @@
 
 Our analysis has focused on the impact of Alice's actions on Alice alone.
 How do Alice's actions (for example, choice of padding method) affect other
-users in the system?
+users in the system? Are there incentive-compatible strategies that provide
+good security for all users?
 
 There are other possible approaches to thwarting traffic analysis, including
 alternative padding regimes (as mentioned above in the discussion for
 Figure~\ref{fig5a}).  These should be investigated.
 
 Although real social networks behave more like scale-free networks than like
-the original disclosure attack's model, there are still more accurate models
-for user behavior than the one we have chosen here.  For example, real users
+the original disclosure attack's model, our models for user behavior
+still have room for improvement.  For example, real users
 probably do not send messages with a geometric distribution independent of
 time: most people's email habits are based on a 24-hour sleep schedule.  The
 effects of this variation may be significant.
@@ -1049,11 +1003,67 @@
 
 % better mix algorithms
 
+\subsubsection{Implications for mix network design:}
+%\label{subsubsec:implications}
+If we were to design a mix network based on our findings here, what steps
+should we take to frustrate intersection attack?
+
+The first lesson is this: {\bf high variability} in message delays is
+essential.  By `spreading' the effects of each incoming message over several
+output rounds, variability in delay increases each message's anonymity set, and
+amplifies the effect of padding.
+
+{\bf Padding} seems to slow traffic analysis, especially as the volume of
+padding approaches the volume of the sender's actual messages,
+drowning out the signal. On the other hand, significant padding may be
+too cumbersome for most users.
+
+Users should be educated about the effects of their chosen {\bf message
+volume}: sending infrequently is safe, especially if the user doesn't
+repeat the same traffic pattern long enough for the attacker to identify
+it. Conversely, sending ``almost always'' is comparatively safe.
+But users in between appear vulnerable to intersection attacks.
+
+%The threat of non-global observers must not be ignored.
+Mix networks should take steps to {\bf minimize the number of messages}
+that a limited attacker can see entering and exiting the network.  Possible
+approaches include encouraging users to run their own mixes; choosing
+messages' entry and exit points to cross geographical and organization
+boundaries; and (of course) increasing the number of mixes in the network.
+
+Much threat analysis for high-latency mix networks aims to provide perfect
+protection against an eavesdropper watching the entire network. We must
+stop asking whether a mix network can forever defend every conceivable
+sender against a global passive adversary.
+%Instead, we must ask _how long_
+%you can defend _which senders_ against an adversary who sees _how much_.
+%We show that mix networks are not secure against this global observer,
+%and that they can also be defeated by partial observers.
+This paper helps move anonymity system threat analysis from inflexible
+security proofs to quantification of risk for given parameters of
+adversaries, senders, and mixes.
+
+% We said that fixed entry/exit might help too, but I now think it 
+% wouldn't.  Suppose the attacker observes c nodes out of n.  If I 
+% choose random paths, the attacker sees (c/n)^2 of my traffic with
+% probability 1.  If I choose a fixed entry, the attacker sees c/n
+% of my traffic with probability c/n.  No real difference.
+%
+% In fact, a limited attacker (P_observe=.2) with a diffuse target should
+% _hope_ that people choose fixed entries.  If they do, then he can
+% eventually make the intersection attack work against the ones who use him
+% as their fixed entry.  But if they _don't_ choose fixed entries, he only
+% sees 4% of everyone's traffic, which is not enough to break anybody.
+%
+% Fixed entries are a good idea for low-latency systems, when a single
+% connection with an attacker on each end compromises a sender--receiver
+% link.
+
 %
 
 \section*{Acknowledgments}
-Thanks go to Gerald Britton, Geoffrey Goodell, Novalis, Peter Palfrader,
-Alistair Riddoch, Pete St. Onge, and Mike Taylor for letting us run our
+Thanks go to Gerald Britton, Geoffrey Goodell, Novalis, Pete St. Onge,
+Peter Palfrader, Alistair Riddoch, and Mike Taylor for letting us run our
 simulations on their computers.
 
 

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