1 |
1 |
deleted file mode 100644
|
... |
... |
@@ -1,226 +0,0 @@
|
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 » </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 — 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 — 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 |
|
-<li>More coming soon. See also the "Research" section of the <a
|
209 |
|
-href="<page getinvolved/volunteer>#Research">volunteer</a> page for
|
210 |
|
-other topics.
|
211 |
|
-</li>
|
212 |
|
-
|
213 |
|
-</ul>
|
214 |
|
-
|
215 |
|
- </div>
|
216 |
|
- <!-- END MAINCOL -->
|
217 |
|
- <div id = "sidecol">
|
218 |
|
-#include "side.wmi"
|
219 |
|
-#include "info.wmi"
|
220 |
|
- </div>
|
221 |
|
- <!-- END SIDECOL -->
|
222 |
|
-</div>
|
223 |
|
-<!-- END CONTENT -->
|
224 |
|
-#include <foot.wmi>
|
225 |
|
-
|