[freehaven-cvs] fix whitespace; add comment

[nickm@seul.org (Nick Mathewson)]

Update of /home/freehaven/cvsroot/doc/e2e-traffic
In directory moria.mit.edu:/tmp/cvs-serv16936

Modified Files:
	e2e-traffic.tex 
Log Message:
fix whitespace; add comment

Index: e2e-traffic.tex
===================================================================
RCS file: /home/freehaven/cvsroot/doc/e2e-traffic/e2e-traffic.tex,v
retrieving revision 1.39
retrieving revision 1.40
diff -u -d -r1.39 -r1.40
--- e2e-traffic.tex	27 Jan 2004 14:17:17 -0000	1.39
+++ e2e-traffic.tex	8 Apr 2004 19:52:53 -0000	1.40
@@ -701,6 +701,9 @@
 %message, and $1/150$ to each element corresponding to an unlikely
 %message.
 
+% Maybe also mention:  What if Alice gets her stats from a given source,
+%  and so prefers different exits?
+
 %======================================================================
 \section{Simulation results}
 \label{sec:simulation}
@@ -740,7 +743,7 @@
 %\label{fig2a}
 %\end{figure}
 
-We present the results of our simulations in Figure~\ref{fig1} 
+We present the results of our simulations in Figure~\ref{fig1}
 (the low-$m$ curves are at the bottom).
 As expected, the attack
 becomes more effective when Alice sends messages to only a few
@@ -978,13 +981,13 @@
 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 
+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
 % to be vulnerable.
 
-% Is this attack better or worse than other attacks?  Probably neither: 
+% Is this attack better or worse than other attacks?  Probably neither:
 % this attack speeds up blending attacks, and relaxes the amount of
 % information that those attacks require to succeed.
 %
@@ -1067,8 +1070,8 @@
 
 
 
-% 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 
+% 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.
@@ -1076,7 +1079,7 @@
 % 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: he breaks 20% of the senders.  
+% as their fixed entry: he breaks 20% of the senders.
 % But if they _don't_ choose fixed entries, he only
 % sees 4% of everyone's traffic, which is not enough to break anybody.
 %
@@ -1084,7 +1087,7 @@
 % 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.  With high-latency systems, however, the number of observed
-% entry/exit pairs matters: so being _certainly_ very seldom observed can 
+% entry/exit pairs matters: so being _certainly_ very seldom observed can
 % be better than being _possibly_ observed somewhat seldom.
 %
 
@@ -1093,7 +1096,6 @@
 Palfrader, Alistair Riddoch, and Mike Taylor for letting us run our
 simulations on their computers.
 
-
 %======================================================================
 \bibliographystyle{plain} \bibliography{e2e-traffic}
 
@@ -1101,4 +1103,4 @@
 
 % 'In order to' -> 'to'
 % very -> damn -> ''
-% 
+%

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