[tor-commits] r26153: {website} Couple more GSoC projects from sjmurdoch (website/trunk/getinvolved/en)

[Damian Johnson]

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">obfsproxy</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.pdf">lots
+    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">μTP</a>, <a
+    href="http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol">SCTP</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