Author: kloesing Date: 2012-08-20 07:23:26 +0000 (Mon, 20 Aug 2012) New Revision: 25760
Removed: website/trunk/getinvolved/en/research.wml Modified: website/trunk/getinvolved/en/sidenav.wmi Log: Remove getinvolved/research which has moved to research.torproject.org
Deleted: website/trunk/getinvolved/en/research.wml =================================================================== --- website/trunk/getinvolved/en/research.wml 2012-08-20 06:12:23 UTC (rev 25759) +++ website/trunk/getinvolved/en/research.wml 2012-08-20 07:23:26 UTC (rev 25760) @@ -1,226 +0,0 @@ -## translation metadata -# Revision: $Revision$ -# Translation-Priority: 4-optional - -#include "head.wmi" TITLE="Tor: Research" CHARSET="UTF-8" -<div id="content" class="clearfix"> - <div id="breadcrumbs"> - <a href="<page index>">Home » </a> - <a href="<page getinvolved/research>">Research</a> - </div> - <div id="maincol"> - <!-- PUT CONTENT AFTER THIS TAG --> -<h2>Tor: Research</h2> -<hr /> - -<p> -Many people around the world are doing research on how to improve the Tor -design, what's going on in the Tor network, and more generally on attacks -and defenses for anonymous communication systems. This page summarizes -the resources we provide to help make your Tor research more effective. -The best way to reach us about research is through the <a href="<page -about/contact>">tor-assistants</a> list. -</p> - -<ul> - -<li> -<b>Data.</b> -We've been <a href="https://metrics.torproject.org/data.html">collecting -data to learn more about the Tor network</a>: how many relays and -clients there are in the network, what capabilities they have, how -fast the network is, how many clients are connecting via bridges, -what traffic exits the network, etc. We are also developing -tools to process these huge data archives and come up with -<a href="https://metrics.torproject.org/graphs.html">useful -statistics</a>. Let us know what other information you'd like to -see, and we can work with you to help make sure it gets collected -<a href="https://metrics.torproject.org/papers/wecsr10.pdf">safely</a> -and robustly. -</li> - -<li> -<b>Analysis.</b> -If you're investigating Tor, or solving a Tor-related problem, -<i>_please_</i> talk to us somewhere along the way — the earlier -the better. These days we review too many conference paper submissions -that make bad assumptions and end up solving the wrong problem. Since -the Tor protocol and the Tor network are both moving targets, measuring -things without understanding what's going on behind the scenes is going -to result in bad conclusions. In particular, different groups often -unwittingly run a variety of experiments in parallel, and at the same -time we're constantly modifying the design to try new approaches. If -you let us know what you're doing and what you're trying to learn, -we can help you understand what other variables to expect and how to -interpret your results. -</li> - -<li> -<b>Measurement and attack tools.</b> -We're building a <a -href="https://metrics.torproject.org/tools.html%22%3Erepository</a> of tools -that can be used to measure, analyze, or perform attacks on Tor. Many -research groups end up needing to do similar measurements (for example, -change the Tor design in some way and then see if latency improves), -and we hope to help everybody standardize on a few tools and then make -them really good. Also, while there are some really neat Tor attacks -that people have published about, it's hard to track down a copy of -the code they used. Let us know if you have new tools we should list, -or improvements to the existing ones. The more the better, at this stage. -</li> - -<li> -<b>We need defenses too — not just attacks.</b> -Most researchers find it easy and fun to come up with novel attacks on -anonymity systems. We've seen this result lately in terms of improved -congestion attacks, attacks based on remotely measuring latency or -throughput, and so on. Knowing how things can go wrong is important, -and we recognize that the incentives in academia aren't aligned with -spending energy on designing defenses, but it sure would be great to -get more attention to how to address the attacks. We'd love to help -brainstorm about how to make Tor better. As a bonus, your paper might -even end up with a stronger "countermeasures" section. -</li> - -<li> -<b>In-person help.</b> -If you're doing interesting and important Tor research and need help -understanding how the Tor network or design works, interpreting your -data, crafting your experiments, etc, we can send a Tor researcher to -your doorstep. As you might expect, we don't have a lot of free time; -but making sure that research is done in a way that's useful to us is -really important. So let us know, and we'll work something out. -</li> - -</ul> - -<a id="Groups"></a> -<h2><a class="anchor" href="#Groups">Research Groups</a></h2> - -<p>Interested to find other anonymity researchers? Here are some -research groups you should take a look at.</p> - -<ul> -<li>Ian Goldberg's <a href="http://crysp.uwaterloo.ca/">CrySP</a> group -at Waterloo. -</li> -<li><a href="http://www-users.cs.umn.edu/~hopper/">Nick Hopper</a>'s -group at UMN. -</li> -<li><a href="http://www.hatswitch.org/~nikita/">Nikita Borisov</a>'s -group at Illinois. -</li> -<li>Micah Sherr's <a href="https://security.cs.georgetown.edu/">SecLab</a> -group at Georgetown. -</li> -<li>Matt Wright's <a href="http://isec.uta.edu/">iSec</a> group at -UTA. -</li> -</ul> - -<a id="Ideas"></a> -<h2><a class="anchor" href="#Ideas">Research Ideas</a></h2> - -<p> -If you're interested in anonymity research, you must make it to the -<a href="http://petsymposium.org/">Privacy Enhancing Technologies -Symposium</a>. Everybody who's anybody in the anonymity research world -will be there. Stipends are generally available for people whose presence -will benefit the community. -</p> - -<p>To get up to speed on anonymity research, read <a -href="http://freehaven.net/anonbib/%22%3Ethese papers</a> (especially the -ones in boxes).</p> - -<p>We need people to attack the system, quantify defenses, -etc. Here are some example projects:</p> - -<ul> - -<li>What algorithm should we use to assign Guard flags such that a) -we assign the flag to as many relays as possible, yet b) we minimize -the chance that Alice will use an attacker's node as a guard? See the -<a href="<blog>/research-problem-better-guard-rotation-parameters">blog -post</a> for details. -</li> - -<li>For various diversity metrics, how has the diversity of -the Tor network changed over time? How robust is it to change or -attack? These results can help us make better design decisions. See the <a -href="<blog>/research-problem-measuring-safety-tor-network">blog post</a> -for details. -</li> - -<li>If we prevent the really loud users from using too much of the Tor -network, how much can it help? We've instrumented Tor's entry relays -so they can rate-limit connections from users, and we've instrumented -the directory authorities so they can change the rate-limiting -parameters globally across the network. Which parameter values improve -performance for the Tor network as a whole? How should relays adapt -their rate-limiting parameters based on their capacity and based on -the network load they see, and what rate-limiting algorithms will work -best? See the <a -href="<blog>/research-problem-adaptive-throttling-tor-clients-entry-guards">blog -post</a> for details. -</li> - -<li>Right now Tor clients are willing to reuse a given circuit for ten -minutes after it's first used. The goal is to avoid loading down the -network with too many circuit creations, yet to also avoid having -clients use the same circuit for so long that the exit node can build a -useful pseudonymous profile of them. Alas, ten minutes is probably way -too long, especially if connections from multiple protocols (e.g. IM and -web browsing) are put on the same circuit. If we keep fixed the overall -number of circuit extends that the network needs to do, are there more -efficient and/or safer ways for clients to allocate streams to circuits, -or for clients to build preemptive circuits? Perhaps this research item -needs to start with gathering some traces of what requests typical -clients try to launch, so you have something realistic to try to optimize. -</li> - -<li>The "website fingerprinting attack": make a list of a few -hundred popular websites, download their pages, and make a set of -"signatures" for each site. Then observe a Tor client's traffic. As -you watch him receive data, you quickly approach a guess about which -(if any) of those sites he is visiting. First, how effective is -this attack on the deployed Tor design? The problem with all the -previous attack papers is that they look at timing and counting of -IP packets on the wire. But OpenSSL's TLS records, plus Tor's use of -TCP pushback to do rate limiting, means that tracing by IP packets -produces very poor results. The right approach is to realize that -Tor uses OpenSSL, look inside the TLS record at the TLS headers, and -figure out how many 512-byte cells are being sent or received. Then -start exploring defenses: for example, we could change Tor's cell -size from 512 bytes to 1024 bytes, we could employ padding techniques -like <a href="http://freehaven.net/anonbib/#timing-fc2004">defensive -dropping</a>, or we could add traffic delays. How much of an impact do -these have, and how much usability impact (using some suitable metric) -is there from a successful defense in each case?</li> - -<!-- -<li> -Path selection algorithms, directory fetching schedules for Tor-on-mobile -that are compatible anonymity-wise with our current approaches. -</li> - ---> - -<li>More coming soon. See also the "Research" section of the <a -href="<page getinvolved/volunteer>#Research">volunteer</a> page for -other topics. -</li> - -</ul> - - </div> - <!-- END MAINCOL --> - <div id = "sidecol"> -#include "side.wmi" -#include "info.wmi" - </div> - <!-- END SIDECOL --> -</div> -<!-- END CONTENT --> -#include <foot.wmi> -
Modified: website/trunk/getinvolved/en/sidenav.wmi =================================================================== --- website/trunk/getinvolved/en/sidenav.wmi 2012-08-20 06:12:23 UTC (rev 25759) +++ website/trunk/getinvolved/en/sidenav.wmi 2012-08-20 07:23:26 UTC (rev 25760) @@ -25,7 +25,7 @@ {'url' => 'getinvolved/relays', 'txt' => 'Set up relays', }, - {'url' => 'getinvolved/research', + {'url' => 'https://research.torproject.org/', 'txt' => 'Research', }, {'url' => 'donate/donate',