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) <div id="content" class="clearfix">
7)   <div id="breadcrumbs">
8)     <a href="<page index>">Home &raquo; </a>
9)     <a href="<page getinvolved/research>">Research</a>
10)   </div>

11)   <div id="maincol">

12)     <!-- PUT CONTENT AFTER THIS TAG -->
13) <h2>Tor: Research</h2>
14) <hr />
15) 
16) <p>
17) Many people around the world are doing research on how to improve the Tor
18) design, what's going on in the Tor network, and more generally on attacks
19) and defenses for anonymous communication systems. This page summarizes
20) the resources we provide to help make your Tor research more effective.
21) The best way to reach us about research is through the <a href="<page

22) about/contact>">tor-assistants</a> list.

23) </p>
24) 
25) <ul>
26) 
27) <li>
28) <b>Data.</b>
29) We've been <a href="https://metrics.torproject.org/data.html">collecting
30) data to learn more about the Tor network</a>: how many relays and
31) clients there are in the network, what capabilities they have, how
32) fast the network is, how many clients are connecting via bridges,
33) what traffic exits the network, etc. We are also developing
34) tools to process these huge data archives and come up with
35) <a href="https://metrics.torproject.org/graphs.html">useful

36) statistics</a>. Let us know what other information you'd like to

37) see, and we can work with you to help make sure it gets collected
38) <a href="https://metrics.torproject.org/papers/wecsr10.pdf">safely</a>
39) and robustly.
40) </li>
41) 
42) <li>
43) <b>Analysis.</b>
44) If you're investigating Tor, or solving a Tor-related problem,
45) <i>_please_</i> talk to us somewhere along the way &mdash; the earlier
46) the better. These days we review too many conference paper submissions
47) that make bad assumptions and end up solving the wrong problem. Since
48) the Tor protocol and the Tor network are both moving targets, measuring
49) things without understanding what's going on behind the scenes is going
50) to result in bad conclusions. In particular, different groups often
51) unwittingly run a variety of experiments in parallel, and at the same
52) time we're constantly modifying the design to try new approaches. If
53) you let us know what you're doing and what you're trying to learn,
54) we can help you understand what other variables to expect and how to
55) interpret your results.
56) </li>
57) 
58) <li>
59) <b>Measurement and attack tools.</b>
60) We're building a <a
61) href="https://metrics.torproject.org/tools.html">repository</a> of tools
62) that can be used to measure, analyze, or perform attacks on Tor. Many
63) research groups end up needing to do similar measurements (for example,
64) change the Tor design in some way and then see if latency improves),
65) and we hope to help everybody standardize on a few tools and then make
66) them really good. Also, while there are some really neat Tor attacks
67) that people have published about, it's hard to track down a copy of
68) the code they used. Let us know if you have new tools we should list,
69) or improvements to the existing ones. The more the better, at this stage.
70) </li>
71) 
72) <li>
73) <b>We need defenses too &mdash; not just attacks.</b>
74) Most researchers find it easy and fun to come up with novel attacks on
75) anonymity systems. We've seen this result lately in terms of improved
76) congestion attacks, attacks based on remotely measuring latency or
77) throughput, and so on. Knowing how things can go wrong is important,
78) and we recognize that the incentives in academia aren't aligned with
79) spending energy on designing defenses, but it sure would be great to
80) get more attention to how to address the attacks. We'd love to help
81) brainstorm about how to make Tor better. As a bonus, your paper might
82) even end up with a stronger "countermeasures" section.
83) </li>
84) 
85) <li>
86) <b>In-person help.</b>
87) If you're doing interesting and important Tor research and need help
88) understanding how the Tor network or design works, interpreting your
89) data, crafting your experiments, etc, we can send a Tor researcher to
90) your doorstep. As you might expect, we don't have a lot of free time;
91) but making sure that research is done in a way that's useful to us is
92) really important. So let us know, and we'll work something out.
93) </li>
94) 
95) </ul>
96) 
97) <a id="Groups"></a>
98) <h2><a class="anchor" href="#Groups">Research Groups</a></h2>
99) 
100) <p>Interested to find other anonymity researchers? Here are some
101) research groups you should take a look at.</p>
102) 
103) <ul>
104) <li>Ian Goldberg's <a href="http://crysp.uwaterloo.ca/">CrySP</a> group
105) at Waterloo.
106) </li>
107) <li><a href="http://www-users.cs.umn.edu/~hopper/">Nick Hopper</a>'s
108) group at UMN.
109) </li>
110) <li><a href="http://www.hatswitch.org/~nikita/">Nikita Borisov</a>'s
111) group at Illinois.
112) </li>

113) <li>Micah Sherr's <a href="https://security.cs.georgetown.edu/">SecLab</a>
114) group at Georgetown.
115) </li>

116) <li>Matt Wright's <a href="http://isec.uta.edu/">iSec</a> group at
117) UTA.
118) </li>
119) </ul>
120) 
121) <a id="Ideas"></a>
122) <h2><a class="anchor" href="#Ideas">Research Ideas</a></h2>
123) 
124) <p>
125) If you're interested in anonymity research, you must make it to the
126) <a href="http://petsymposium.org/">Privacy Enhancing Technologies
127) Symposium</a>. Everybody who's anybody in the anonymity research world

128) will be there. Stipends are generally available for people whose presence
129) will benefit the community.

130) </p>
131) 
132) <p>To get up to speed on anonymity research, read <a
133) href="http://freehaven.net/anonbib/">these papers</a> (especially the
134) ones in boxes).</p>
135) 
136) <p>We need people to attack the system, quantify defenses,
137) etc. Here are some example projects:</p>
138) 
139) <ul>
140) 

141) <li>What algorithm should we use to assign Guard flags such that a)
142) we assign the flag to as many relays as possible, yet b) we minimize
143) the chance that Alice will use an attacker's node as a guard? See the
144) <a href="<blog>/research-problem-better-guard-rotation-parameters">blog
145) post</a> for details.
146) </li>
147) 

148) <li>For various diversity metrics, how has the diversity of
149) the Tor network changed over time? How robust is it to change or
150) attack? These results can help us make better design decisions. See the <a
151) href="<blog>/research-problem-measuring-safety-tor-network">blog post</a>
152) for details.
153) </li>
154) 

155) <li>If we prevent the really loud users from using too much of the Tor
156) network, how much can it help? We've instrumented Tor's entry relays
157) so they can rate-limit connections from users, and we've instrumented
158) the directory authorities so they can change the rate-limiting
159) parameters globally across the network. Which parameter values improve
160) performance for the Tor network as a whole? How should relays adapt
161) their rate-limiting parameters based on their capacity and based on
162) the network load they see, and what rate-limiting algorithms will work
163) best? See the <a
164) href="<blog>/research-problem-adaptive-throttling-tor-clients-entry-guards">blog
165) post</a> for details.
166) </li>
167) 
168) <li>Right now Tor clients are willing to reuse a given circuit for ten
169) minutes after it's first used. The goal is to avoid loading down the
170) network with too many circuit creations, yet to also avoid having
171) clients use the same circuit for so long that the exit node can build a
172) useful pseudonymous profile of them. Alas, ten minutes is probably way
173) too long, especially if connections from multiple protocols (e.g. IM and
174) web browsing) are put on the same circuit. If we keep fixed the overall
175) number of circuit extends that the network needs to do, are there more
176) efficient and/or safer ways for clients to allocate streams to circuits,
177) or for clients to build preemptive circuits? Perhaps this research item
178) needs to start with gathering some traces of what requests typical
179) clients try to launch, so you have something realistic to try to optimize.
180) </li>
181) 
182) <li>The "website fingerprinting attack": make a list of a few
183) hundred popular websites, download their pages, and make a set of
184) "signatures" for each site. Then observe a Tor client's traffic. As
185) you watch him receive data, you quickly approach a guess about which
186) (if any) of those sites he is visiting. First, how effective is
187) this attack on the deployed Tor design? The problem with all the
188) previous attack papers is that they look at timing and counting of
189) IP packets on the wire. But OpenSSL's TLS records, plus Tor's use of
190) TCP pushback to do rate limiting, means that tracing by IP packets
191) produces very poor results. The right approach is to realize that
192) Tor uses OpenSSL, look inside the TLS record at the TLS headers, and
193) figure out how many 512-byte cells are being sent or received. Then
194) start exploring defenses: for example, we could change Tor's cell
195) size from 512 bytes to 1024 bytes, we could employ padding techniques
196) like <a href="http://freehaven.net/anonbib/#timing-fc2004">defensive
197) dropping</a>, or we could add traffic delays. How much of an impact do
198) these have, and how much usability impact (using some suitable metric)
199) is there from a successful defense in each case?</li>
200) 
201) <!--
202) <li>
203) Path selection algorithms, directory fetching schedules for Tor-on-mobile
204) that are compatible anonymity-wise with our current approaches.
205) </li>
206) 
207) -->
208) 

209) <li>More coming soon. See also the "Research" section of the <a
210) href="<page getinvolved/volunteer>#Research">volunteer</a> page for
211) other topics.

212) </li>
213) 
214) </ul>
215) 
216)   </div>
217)   <!-- END MAINCOL -->
218)   <div id = "sidecol">
219) #include "side.wmi"
220) #include "info.wmi"
221)   </div>
222)   <!-- END SIDECOL -->
223) </div>
224) <!-- END CONTENT -->