Author: atagar Date: 2013-04-09 16:41:49 +0000 (Tue, 09 Apr 2013) New Revision: 26153

Modified: website/trunk/getinvolved/en/volunteer.wml Log: Couple more GSoC projects from sjmurdoch

Modified: website/trunk/getinvolved/en/volunteer.wml =================================================================== --- website/trunk/getinvolved/en/volunteer.wml 2013-04-09 16:05:53 UTC (rev 26152) +++ website/trunk/getinvolved/en/volunteer.wml 2013-04-09 16:41:49 UTC (rev 26153) @@ -603,6 +603,11 @@ block Tor. This has both a C and python implementation. </p>

+ <p> + <b>Project Ideas:</b><br /> + <i><a href="#betterPluggableTransports">Build Better Pluggable Transports</a></i> + </p> + <a id="project-flash-proxy"></a> <h3><a href="https://crypto.stanford.edu/flashproxy/">Flash Proxy</a> (<a href="https://gitweb.torproject.org/flashproxy.git">code</a>, <a @@ -1270,7 +1275,62 @@ </p> </li>

+ <a id="betterPluggableTransports"></a> <li> + <b>Build Better Pluggable Transports</b> + <br> + Effort Level: <i>Medium to High</i> + <br> + Skill Level: <i>Medium</i> + <br> + Likely Mentors: <i>Steven (sjmurdoch)</i> + <p> + For Tor users in censored countries, we currently offer <a + href="https://www.torproject.org/projects/obfsproxy.html.en%22%3Eobfsproxy</a> + bridges, which disguise Tor traffic by making it look random. This works + for many users, but it has disadvantages: firstly it does not disguise + packet size and secondly it looks like no real protocol. These weaknesses + may result in obfsproxy being blocked. + </p> + + <p> + The goal for this project will be to implement new pluggable transports, + which resolve these weaknesses and so can be deployed if/when obfsproxy is + blocked. Ideas for doing so include: + <ul> + <li>Impersonate a voice-over-IP protocol</li> + <li>Impersonate HTTP sufficiently well that traffic will go through a HTTP-only proxy</li> + <li>Implement <a href="http://cacr.uwaterloo.ca/techreports/2011/cacr2011-21.pdf">scanning resistance</a></a> + </ul> + </p> + + <a id="profileUDPTransport"></a> + <li> + <b>Profile UDP transport protocols</b> + <br> + Effort Level: <i>Medium to High</i> + <br> + Skill Level: <i>High</i> + <br> + Likely Mentors: <i>Steven (sjmurdoch)</i> + <p> + There are <a + href="https://research.torproject.org/techreports/datagram-comparison-2011-11-07.p... + of options</a> as to how Tor could send its data over UDP rather than TCP, + and some will likely perform significantly better than others. This project + will evaluate these options, so as to decide which should be used in future + versions of Tor. A first step will be to benchmark the various transport + protocols being considered, in terms of performance and also code quality, + including userspace TCP, <a + href="https://github.com/bittorrent/libutp%22%3E%CE%BCTP</a>, <a + href="http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol%22%3ESCTP</a> + and <a href="http://curvecp.org/">CurveCP</a>. Initially these transport + protocols will be examined in isolation, but if the project progresses well + one or more could be integrated in Tor. + </p> + </li> + + <li> <b>Bring up new ideas!</b> <br> Don't like any of these? Look at the <a