[tor-commits] [webwml/staging] Core tor GSoC project ideas

hiro at torproject.org hiro at torproject.org
Sun Mar 5 20:51:16 UTC 2017


commit b4db53b1539aa0dc92009c73d25e8c44de6f6e41
Author: Damian Johnson <atagar at torproject.org>
Date:   Mon Feb 27 11:53:28 2017 -0800

    Core tor GSoC project ideas
    
    Nick has been leading discussions with core tor folks concerning some GSoC
    project ideas. Adding what they've come up with...
    
      https://storm.torproject.org/shared/Xh2gRt-Oy__EaM8_4DAIhrYFMXbOnC09AfLGbHx7TUG
---
 getinvolved/en/volunteer.wml | 169 ++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 168 insertions(+), 1 deletion(-)

diff --git a/getinvolved/en/volunteer.wml b/getinvolved/en/volunteer.wml
index e276865..3f70741 100644
--- a/getinvolved/en/volunteer.wml
+++ b/getinvolved/en/volunteer.wml
@@ -395,7 +395,14 @@ meetings around the world.</li>
 
     <p>
     <b>Project Ideas:</b><br />
-    <i><a href="#improveHiddenServices">Help improve Tor hidden services</a></i>
+    <i><a href="#improveHiddenServices">Help improve Tor hidden services</a></i><br />
+    <i><a href="#torFuzzing">Fuzzing coverage of Tor</a></i><br />
+    <i><a href="#relayCryptoParallelism">Relay crypto parallelism</a></i><br />
+    <i><a href="#anonymousLocalCountStatistics">Anonymous local count statistics</a></i><br />
+    <i><a href="#improveSocks5Variant">Improved SOCKS5 variant</a></i><br />
+    <i><a href="#hiddenServiceCryptoParallelism">Hidden service crypto parallelism</a></i><br />
+    <i><a href="#supportAllDNS">Support all kinds of DNS in Tor</a></i><br />
+    <i><a href="#improveIpv6Support">Improve IPv6 support</a></i>
     </p>
 
     <a id="project-torbrowser"></a>
@@ -835,6 +842,166 @@ ideas.
     </p>
     </li>
 
+    <a id="torFuzzing"></a>
+    <li>
+    <b>Fuzzing coverage of Tor</b>
+    <br>
+    Likely Mentors: <i>Nick (nickm), ahf, teor</i>
+    <br><br>
+    <p>
+Starting in 0.3.0.x, Tor supports a few fuzzing systems to check our
+code for bugs.  But as of now, we only support a few possible entry
+points to Tor.  It would be great to add fuzzing support for more of
+our codebase -- ideally to include our whole network-facing interface.
+That way, we could find more bugs in our code faster, and fix them
+before they can get out of hand.
+    </p>
+
+    <p>
+This won't be so easy, however: to fuzz effectively, we need to
+refactor or mock the target function so that it doesn't change any
+global state, or verify any signatures, or take too long to run.  With
+lots of our network code, that's not so easy.  Make sure you
+understand how our mocking system works, and what the challenges are,
+before you apply for this one.
+    </p>
+    </li>
+
+    <a id="relayCryptoParallelism"></a>
+    <li>
+    <b>Relay crypto parallelism</b>
+    <br>
+    Likely Mentors: <i>Isis, Nick (nickm)</i>
+    <br><br>
+    <p>
+Tor relays spend a lot of time encrypting and decrypting relay
+traffic, doing SHA1 and AES-CTR operations.  But right now, all of
+this is done in the main thread!  It would be cool to split this
+across multiple cores instead.
+    </p>
+
+    <p>
+This won't be so easy though.  The code today is written to expect
+immediate results from its encryption operations, so you would need to
+do some pretty tricky refactoring in order get performance and
+correctness here.  Make sure you understand how circuit crypto is
+invoked today, and what the challenges are, before you apply for this
+one.
+    </p>
+
+    <p>
+For more information <a href="https://trac.torproject.org/projects/tor/ticket/1749">see its ticket</a>.
+    </p>
+    </li>
+
+    <a id="anonymousLocalCountStatistics"></a>
+    <li>
+    <b>Anonymous local count statistics</b>
+    <br>
+    Likely Mentors: <i>Nick (nickm), teor</i>
+    <br><br>
+    <p>
+There are some places in Tor where we count things (like distinct IPs)
+to later report anonymized statistics.  But if the local Tor instance
+were compromised, this data would be exposed.  There are statistical
+methods which insteasd allow us to record this data in a way that's
+already anonymous, before we ever summarize it.  Interested?
+    </p>
+
+    <p>
+For more information <a href="https://trac.torproject.org/projects/tor/ticket/7532">see its ticket</a>.
+    </p>
+    </li>
+
+    <a id="improveSocks5Variant"></a>
+    <li>
+    <b>Improved SOCKS5 variant</b>
+    <br>
+    Likely Mentors: <i>Nick (nickm), David Goulet (dgoulet)</i>
+    <br><br>
+    <p>
+In proposal 229, we describe a bunch of additional SOCKS extensions
+that Tor-aware applications could use to get more fine-grained control
+over how Tor handles their streams.  It would be cool to implement
+this!  If there's time remaining, you might want to add support to one
+or more applications.  Or maybe to torsocks?
+    </p>
+
+    <p>
+For more information <a href="https://trac.torproject.org/projects/tor/ticket/12456">see its ticket</a>.
+    </p>
+    </li>
+
+    <a id="hiddenServiceCryptoParallelism"></a>
+    <li>
+    <b>Hidden service crypto parallelism</b>
+    <br>
+    Likely Mentors: <i>Nick (nickm), David Goulet (dgoulet)</i>
+    <br><br>
+    <p>
+Hidden services, hidden service clients, hidden service directories,
+and introduction points all need to do a few public-key operations as
+they operate.  But right now, these operations are all done on the
+main thread.  It would be good to have these run across multiple cores.
+    </p>
+
+    <p>
+This could probably be done in a way similar to how we currently hand
+circuit extension handshakes in onion.c and cpuworker.c, but we'd need
+to extend the state machine for hidden services to add an additional
+state.  It could help hidden services operate much more efficiently.
+    </p>
+
+    <p>
+For more information <a href="https://trac.torproject.org/projects/tor/ticket/13738">see its ticket</a>.
+    </p>
+    </li>
+
+    <a id="supportAllDNS"></a>
+    <li>
+    <b>Support all kinds of DNS in Tor</b>
+    <br>
+    Likely Mentors: <i>Nick (nickm), George (asn)</i>
+    <br><br>
+    <p>
+Right now Tor can query for the kind of DNS information you'd find in
+A records, AAAA records, and PTR records.  It would be neat to be able
+to support more general DNS queries to allow things like MX loopups,
+DNSSEC lookups, and so on.  We have a design proposal (number 219) for
+this, but it might need some clean-up.
+    </p>
+
+    <p>
+For more information <a href="https://trac.torproject.org/projects/tor/ticket/7829">see its ticket</a>.
+    </p>
+    </li>
+
+    <a id="improveIpv6Support"></a>
+    <li>
+    <b>Improve IPv6 support</b>
+    <br>
+    Likely Mentors: <i>ahf, teor</i>
+    <br><br>
+    <p>
+Tor works over IPv6, but require some manual configuration.
+Clients and relays could automatically detect IPv6 availability,
+and configure themselves appropriately. Implementing a
+"happy eyeballs"-like algorithm is a challenge in an anonymity
+network: are you up for it?
+    </p>
+
+    <ul>
+      <li><a href="https://trac.torproject.org/projects/tor/ticket/6939">Missing IPv6 ORPort reachability check</a></li>
+      <li><a href="https://trac.torproject.org/projects/tor/ticket/4847">Bridges binding only to an IPv6 address doesn't work</a></li>
+      <li><a href="https://trac.torproject.org/projects/tor/ticket/5940">Figure out own IPv6 address</a></li>
+      <li><a href="https://trac.torproject.org/projects/tor/ticket/17011">Teach chutney to verify over IPv6</a></li>
+    </ul>
+
+    <p>
+For more information <a href="https://trac.torproject.org/projects/tor/ticket/17811">see its ticket</a>.
+    </p>
+    </li>
+
     <a id="feedbackExtension"></a>
     <li>
     <b>Feedback Extension for Tor Browser</b>





More information about the tor-commits mailing list