tor-webwml.git

1) ## translation metadata

2) # Revision: $Revision$

3) # Translation-Priority: 4-optional

4) 

5) #include "head.wmi" TITLE="Tor: Research" CHARSET="UTF-8"

6) 
7) <div class="main-column">
8) 
9) <h2>Tor: Research</h2>
10) <hr />
11) 

12) <p>
13) Many people around the world are doing research on how to improve the Tor
14) design, what's going on in the Tor network, and more generally on attacks
15) and defenses for anonymous communication systems. This page summarizes
16) the resources we provide to help make your Tor research more effective.
17) The best way to reach us about research is through the <a href="<page
18) contact>">tor-assistants</a> list.
19) </p>
20) 
21) <ul>
22) 
23) <li>
24) <b>Data.</b>
25) We've been <a href="http://metrics.torproject.org/data.html">collecting
26) data to learn more about the Tor network</a>: how many relays and
27) clients there are in the network, what capabilities they have, how
28) fast the network is, how many clients are connecting via bridges,
29) what traffic exits the network, etc. We are also developing
30) tools to process these huge data archives and come up with
31) <a href="http://metrics.torproject.org/graphs.html">useful
32) statistics</a>.  For example, we provide a <a
33) href="https://gitweb.torproject.org//ernie.git?a=blob_plain;f=doc/manual.pdf">tool
34) called Ernie</a> that can import relay descriptors into a local database
35) to perform analyses. Let us know what other information you'd like to

36) see, and we can work with you to help make sure it gets collected
37) <a href="http://metrics.torproject.org/papers/wecsr10.pdf">safely</a>

38) and robustly.
39) </li>
40) 
41) <li>
42) <b>Analysis.</b>
43) If you're investigating Tor, or solving a Tor-related problem,
44) <i>_please_</i> talk to us somewhere along the way &mdash; the earlier
45) the better. These days we review too many conference paper submissions
46) that make bad assumptions and end up solving the wrong problem. Since
47) the Tor protocol and the Tor network are both moving targets, measuring
48) things without understanding what's going on behind the scenes is going
49) to result in bad conclusions. In particular, different groups often
50) unwittingly run a variety of experiments in parallel, and at the same
51) time we're constantly modifying the design to try new approaches. If
52) you let us know what you're doing and what you're trying to learn,
53) we can help you understand what other variables to expect and how to
54) interpret your results.
55) </li>
56) 
57) <li>
58) <b>Measurement and attack tools.</b>
59) We're building a <a
60) href="http://metrics.torproject.org/tools.html">repository</a> of tools
61) that can be used to measure, analyze, or perform attacks on Tor. Many
62) research groups end up needing to do similar measurements (for example,
63) change the Tor design in some way and then see if latency improves),
64) and we hope to help everybody standardize on a few tools and then make
65) them really good. Also, while there are some really neat Tor attacks
66) that people have published about, it's hard to track down a copy of
67) the code they used. Let us know if you have new tools we should list,
68) or improvements to the existing ones. The more the better, at this stage.
69) </li>
70) 

71) <li>
72) <b>We need defenses too &mdash; not just attacks.</b>
73) Most researchers find it easy and fun to come up with novel attacks on
74) anonymity systems. We've seen this result lately in terms of improved
75) congestion attacks, attacks based on remotely measuring latency or
76) throughput, and so on. Knowing how things can go wrong is important,
77) and we recognize that the incentives in academia aren't aligned with
78) spending energy on designing defenses, but it sure would be great to
79) get more attention to how to address the attacks. We'd love to help
80) brainstorm about how to make Tor better. As a bonus, your paper might
81) even end up with a stronger "countermeasures" section.
82) </li>
83) 

84) <li>
85) <b>In-person help.</b>
86) If you're doing interesting and important Tor research and need help
87) understanding how the Tor network or design works, interpreting your
88) data, crafting your experiments, etc, we can send a Tor researcher to
89) your doorstep. As you might expect, we don't have a lot of free time;
90) but making sure that research is done in a way that's useful to us is
91) really important. So let us know, and we'll work something out.
92) </li>
93) 
94) </ul>
95) 
96) <a id="Groups"></a>

97) <h2><a class="anchor" href="#Groups">Research Groups</a></h2>

98) 
99) <p>Interested to find other anonymity researchers? Here are some
100) research groups you should take a look at.</p>
101) 
102) <ul>
103) <li>Ian Goldberg's <a href="http://crysp.uwaterloo.ca/">CrySP</a> group
104) at Waterloo.
105) </li>
106) <li><a href="http://www-users.cs.umn.edu/~hopper/">Nick Hopper</a>'s
107) group at UMN.
108) </li>
109) <li><a href="http://www.hatswitch.org/~nikita/">Nikita Borisov</a>'s
110) group at Illinois.
111) </li>
112) <li>Matt Wright's <a href="http://isec.uta.edu/">iSec</a> group at
113) UTA.

114) </li>

115) </ul>
116) 
117) <a id="Ideas"></a>
118) <h2><a class="anchor" href="#Ideas">Research Ideas</a></h2>
119) 
120) <p>
121) If you're interested in anonymity research, you must make it to the
122) <a href="http://petsymposium.org/">Privacy Enhancing Technologies
123) Symposium</a>. Everybody who's anybody in the anonymity research world
124) will be there. The 2010 conference is in Berlin in July. Stipends are
125) available for people whose presence will benefit the community.
126) </p>
127) 
128) <p>To get up to speed on anonymity research, read <a
129) href="http://freehaven.net/anonbib/">these papers</a> (especially the
130) ones in boxes).</p>

131) 
132) <p>We need people to attack the system, quantify defenses,

133) etc. Here are some example projects:</p>

134) 
135) <ul>
136) 
137) <li>The "website fingerprinting attack": make a list of a few
138) hundred popular websites, download their pages, and make a set of
139) "signatures" for each site. Then observe a Tor client's traffic. As
140) you watch him receive data, you quickly approach a guess about which
141) (if any) of those sites he is visiting. First, how effective is
142) this attack on the deployed Tor design? The problem with all the
143) previous attack papers is that they look at timing and counting of
144) IP packets on the wire. But OpenSSL's TLS records, plus Tor's use of
145) TCP pushback to do rate limiting, means that tracing by IP packets
146) produces very poor results. The right approach is to realize that
147) Tor uses OpenSSL, look inside the TLS record at the TLS headers, and
148) figure out how many 512-byte cells are being sent or received. Then
149) start exploring defenses: for example, we could change Tor's cell
150) size from 512 bytes to 1024 bytes, we could employ padding techniques
151) like <a href="http://freehaven.net/anonbib/#timing-fc2004">defensive
152) dropping</a>, or we could add traffic delays. How much of an impact do
153) these have, and how much usability impact (using some suitable metric)
154) is there from a successful defense in each case?</li>
155) 
156) <!--
157) <li>
158) Path selection algorithms, directory fetching schedules for Tor-on-mobile
159) that are compatible anonymity-wise with our current approaches.
160) </li>
161) 
162) <li>
163) Figure out how bad 10 minutes is for maxcircuitdirtiness.
164) </li>
165) -->
166) 
167) <li>More coming soon. See also the "Research" section of the
168) <a href="<page volunteer>#Research">volunteer</a> page for other topics.
169) </li>
170) 
171) </ul>