[or-cvs] one pony is not enough.

[arma@xxxxxxxx]

Update of /home2/or/cvsroot/website
In directory moria:/home/arma/work/onion/cvs/website

Modified Files:
	volunteer.html 
Log Message:
one pony is not enough.


Index: volunteer.html
===================================================================
RCS file: /home2/or/cvsroot/website/volunteer.html,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -d -r1.25 -r1.26
--- volunteer.html	23 Sep 2005 20:17:33 -0000	1.25
+++ volunteer.html	24 Sep 2005 22:03:25 -0000	1.26
@@ -252,6 +252,16 @@
 is confident he has won? Are there scenarios (e.g. not transmitting much)
 that slow down the attack? Do some traffic padding or traffic shaping
 schemes work better than others?</li>
+<li>The "run two servers and wait attack": Tor clients pick a new path
+periodically. If the adversary runs an entry and an exit, eventually some
+Alice will build a circuit that begins and ends with his nodes. The
+current Tor threat model assumes the end-to-end traffic confirmation attack
+is trivial, and instead aims to limit the chance that the adversary will
+be able to see both sides of a circuit. One way to help this is 
+<a href="http://freehaven.net/anonbib/#wright03";>helper
+nodes</a> -- Alice picks a small set of entry nodes and uses them always.
+But in reality, Tor nodes disappear sometimes. So it would seem that the
+attack continues, albeit slower than before. How much slower?</li>
 <li>The "routing zones attack": most of the literature thinks of
 the network path between Alice and her entry node (and between the
 exit node and Bob) as a single link on some graph. In practice,
@@ -262,7 +272,6 @@
 exit, Bob quad will be dangerous, we need to download an entire Internet
 routing zone and perform expensive operations on it. Are there practical
 approximations, such as avoiding IP addresses in the same /8 network?</li>
-<!--<li>Find ideal churn rate for helper nodes; how safe is it?</li> -->
 <li>Tor doesn't work very well when servers have asymmetric bandwidth
 (e.g. cable or DSL). Because Tor has separate TCP connections between
 each hop, if the incoming bytes are arriving just fine and the outgoing
@@ -292,9 +301,16 @@
 good dissidents in an automated way that doesn't let the country-level
 firewalls intercept and enumerate them? Probably needs to work on a
 human-trust level.</li>
-<!-- <li>Is exiting from the middle of the circuit always a bad idea?</li>
-<li>It's not that hard to DoS Tor servers or dirservers. Are puzzles the
-right answer? What other practical approaches are there?</li> -->
+<li>Tor circuits are built one hop at a time, so in theory we have the
+ability to make some streams exit from the second hop, some from the
+third, and so on. This seems nice because it breaks up the set of exiting
+streams that a given server can see. But if we want each stream to be safe,
+the "shortest" path should be at least 3 hops long by our current logic, so
+the rest will be even longer. We need to examine this performance / security
+tradeoff.</li>
+<li>It's not that hard to DoS Tor servers or dirservers. Are client
+puzzles the right answer? What other practical approaches are there? Bonus
+if they're backward-compatible with the current Tor protocol.</li>
 </ol>
 
 Drop by the #tor IRC channel at irc.oftc.net or email tor-volunteer@xxxxxxxxxxxxx if you want to help out!