create the research page. (09384dfdb) - tor-webwml.git

...	...	@@ -0,0 +1,210 @@
	1	+## translation metadata
	2	+# Revision: $Revision: 23487 $
	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	+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>. For example, we provide a <a
	37	+href="https://gitweb.torproject.org//ernie.git?a=blob_plain;f=doc/manual.pdf">tool
	38	+called Ernie</a> that can import relay descriptors into a local database
	39	+to perform analyses. Let us know what other information you'd like to
	40	+see, and we can work with you to help make sure it gets collected
	41	+<a href="https://metrics.torproject.org/papers/wecsr10.pdf">safely</a>
	42	+and robustly.
	43	+</li>
	44	+
	45	+<li>
	46	+<b>Analysis.</b>
	47	+If you're investigating Tor, or solving a Tor-related problem,
	48	+<i>_please_</i> talk to us somewhere along the way — the earlier
	49	+the better. These days we review too many conference paper submissions
	50	+that make bad assumptions and end up solving the wrong problem. Since
	51	+the Tor protocol and the Tor network are both moving targets, measuring
	52	+things without understanding what's going on behind the scenes is going
	53	+to result in bad conclusions. In particular, different groups often
	54	+unwittingly run a variety of experiments in parallel, and at the same
	55	+time we're constantly modifying the design to try new approaches. If
	56	+you let us know what you're doing and what you're trying to learn,
	57	+we can help you understand what other variables to expect and how to
	58	+interpret your results.
	59	+</li>
	60	+
	61	+<li>
	62	+<b>Measurement and attack tools.</b>
	63	+We're building a <a
	64	+href="https://metrics.torproject.org/tools.html">repository</a> of tools
	65	+that can be used to measure, analyze, or perform attacks on Tor. Many
	66	+research groups end up needing to do similar measurements (for example,
	67	+change the Tor design in some way and then see if latency improves),
	68	+and we hope to help everybody standardize on a few tools and then make
	69	+them really good. Also, while there are some really neat Tor attacks
	70	+that people have published about, it's hard to track down a copy of
	71	+the code they used. Let us know if you have new tools we should list,
	72	+or improvements to the existing ones. The more the better, at this stage.
	73	+</li>
	74	+
	75	+<li>
	76	+<b>We need defenses too — not just attacks.</b>
	77	+Most researchers find it easy and fun to come up with novel attacks on
	78	+anonymity systems. We've seen this result lately in terms of improved
	79	+congestion attacks, attacks based on remotely measuring latency or
	80	+throughput, and so on. Knowing how things can go wrong is important,
	81	+and we recognize that the incentives in academia aren't aligned with
	82	+spending energy on designing defenses, but it sure would be great to
	83	+get more attention to how to address the attacks. We'd love to help
	84	+brainstorm about how to make Tor better. As a bonus, your paper might
	85	+even end up with a stronger "countermeasures" section.
	86	+</li>
	87	+
	88	+<li>
	89	+<b>In-person help.</b>
	90	+If you're doing interesting and important Tor research and need help
	91	+understanding how the Tor network or design works, interpreting your
	92	+data, crafting your experiments, etc, we can send a Tor researcher to
	93	+your doorstep. As you might expect, we don't have a lot of free time;
	94	+but making sure that research is done in a way that's useful to us is
	95	+really important. So let us know, and we'll work something out.
	96	+</li>
	97	+
	98	+</ul>
	99	+
	100	+<a id="Groups"></a>
	101	+<h2><a class="anchor" href="#Groups">Research Groups</a></h2>
	102	+
	103	+<p>Interested to find other anonymity researchers? Here are some
	104	+research groups you should take a look at.</p>
	105	+
	106	+<ul>
	107	+<li>Ian Goldberg's <a href="http://crysp.uwaterloo.ca/">CrySP</a> group
	108	+at Waterloo.
	109	+</li>
	110	+<li><a href="http://www-users.cs.umn.edu/~hopper/">Nick Hopper</a>'s
	111	+group at UMN.
	112	+</li>
	113	+<li><a href="http://www.hatswitch.org/~nikita/">Nikita Borisov</a>'s
	114	+group at Illinois.
	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. The 2010 conference is in Berlin in July. Stipends are
	129	+available for people whose presence 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>If we prevent the really loud users from using too much of the Tor
	142	+network, how much can it help? We've instrumented Tor's entry relays
	143	+so they can rate-limit connections from users, and we've instrumented
	144	+the directory authorities so they can change the rate-limiting
	145	+parameters globally across the network. Which parameter values improve
	146	+performance for the Tor network as a whole? How should relays adapt
	147	+their rate-limiting parameters based on their capacity and based on
	148	+the network load they see, and what rate-limiting algorithms will work
	149	+best? See the <a
	150	+href="<blog>/research-problem-adaptive-throttling-tor-clients-entry-guards">blog
	151	+post</a> for details.
	152	+</li>
	153	+
	154	+<li>Right now Tor clients are willing to reuse a given circuit for ten
	155	+minutes after it's first used. The goal is to avoid loading down the
	156	+network with too many circuit creations, yet to also avoid having
	157	+clients use the same circuit for so long that the exit node can build a
	158	+useful pseudonymous profile of them. Alas, ten minutes is probably way
	159	+too long, especially if connections from multiple protocols (e.g. IM and
	160	+web browsing) are put on the same circuit. If we keep fixed the overall
	161	+number of circuit extends that the network needs to do, are there more
	162	+efficient and/or safer ways for clients to allocate streams to circuits,
	163	+or for clients to build preemptive circuits? Perhaps this research item
	164	+needs to start with gathering some traces of what requests typical
	165	+clients try to launch, so you have something realistic to try to optimize.
	166	+</li>
	167	+
	168	+<li>The "website fingerprinting attack": make a list of a few
	169	+hundred popular websites, download their pages, and make a set of
	170	+"signatures" for each site. Then observe a Tor client's traffic. As
	171	+you watch him receive data, you quickly approach a guess about which
	172	+(if any) of those sites he is visiting. First, how effective is
	173	+this attack on the deployed Tor design? The problem with all the
	174	+previous attack papers is that they look at timing and counting of
	175	+IP packets on the wire. But OpenSSL's TLS records, plus Tor's use of
	176	+TCP pushback to do rate limiting, means that tracing by IP packets
	177	+produces very poor results. The right approach is to realize that
	178	+Tor uses OpenSSL, look inside the TLS record at the TLS headers, and
	179	+figure out how many 512-byte cells are being sent or received. Then
	180	+start exploring defenses: for example, we could change Tor's cell
	181	+size from 512 bytes to 1024 bytes, we could employ padding techniques
	182	+like <a href="http://freehaven.net/anonbib/#timing-fc2004">defensive
	183	+dropping</a>, or we could add traffic delays. How much of an impact do
	184	+these have, and how much usability impact (using some suitable metric)
	185	+is there from a successful defense in each case?</li>
	186	+
	187	+<!--
	188	+<li>
	189	+Path selection algorithms, directory fetching schedules for Tor-on-mobile
	190	+that are compatible anonymity-wise with our current approaches.
	191	+</li>
	192	+
	193	+-->
	194	+
	195	+<li>More coming soon. See also the "Research" section of the
	196	+<a href="<page volunteer>#Research">volunteer</a> page for other topics.
	197	+</li>
	198	+
	199	+</ul>
	200	+
	201	+ </div>
	202	+ <!-- END MAINCOL -->
	203	+ <div id = "sidecol">
	204	+#include "side.wmi"
	205	+#include "info.wmi"
	206	+ </div>
	207	+ <!-- END SIDECOL -->
	208	+</div>
	209	+<!-- END CONTENT -->
	210	+#include <foot.wmi>
0	211