Browse code

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

Damian Johnson authored on27/02/2017 20:53:28
Showing1 changed files
... ...
@@ -395,7 +395,14 @@ meetings around the world.</li>
395 395
 
396 396
     <p>
397 397
     <b>Project Ideas:</b><br />
398
-    <i><a href="#improveHiddenServices">Help improve Tor hidden services</a></i>
398
+    <i><a href="#improveHiddenServices">Help improve Tor hidden services</a></i><br />
399
+    <i><a href="#torFuzzing">Fuzzing coverage of Tor</a></i><br />
400
+    <i><a href="#relayCryptoParallelism">Relay crypto parallelism</a></i><br />
401
+    <i><a href="#anonymousLocalCountStatistics">Anonymous local count statistics</a></i><br />
402
+    <i><a href="#improveSocks5Variant">Improved SOCKS5 variant</a></i><br />
403
+    <i><a href="#hiddenServiceCryptoParallelism">Hidden service crypto parallelism</a></i><br />
404
+    <i><a href="#supportAllDNS">Support all kinds of DNS in Tor</a></i><br />
405
+    <i><a href="#improveIpv6Support">Improve IPv6 support</a></i>
399 406
     </p>
400 407
 
401 408
     <a id="project-torbrowser"></a>
... ...
@@ -835,6 +842,166 @@ ideas.
835 842
     </p>
836 843
     </li>
837 844
 
845
+    <a id="torFuzzing"></a>
846
+    <li>
847
+    <b>Fuzzing coverage of Tor</b>
848
+    <br>
849
+    Likely Mentors: <i>Nick (nickm), ahf, teor</i>
850
+    <br><br>
851
+    <p>
852
+Starting in 0.3.0.x, Tor supports a few fuzzing systems to check our
853
+code for bugs.  But as of now, we only support a few possible entry
854
+points to Tor.  It would be great to add fuzzing support for more of
855
+our codebase -- ideally to include our whole network-facing interface.
856
+That way, we could find more bugs in our code faster, and fix them
857
+before they can get out of hand.
858
+    </p>
859
+
860
+    <p>
861
+This won't be so easy, however: to fuzz effectively, we need to
862
+refactor or mock the target function so that it doesn't change any
863
+global state, or verify any signatures, or take too long to run.  With
864
+lots of our network code, that's not so easy.  Make sure you
865
+understand how our mocking system works, and what the challenges are,
866
+before you apply for this one.
867
+    </p>
868
+    </li>
869
+
870
+    <a id="relayCryptoParallelism"></a>
871
+    <li>
872
+    <b>Relay crypto parallelism</b>
873
+    <br>
874
+    Likely Mentors: <i>Isis, Nick (nickm)</i>
875
+    <br><br>
876
+    <p>
877
+Tor relays spend a lot of time encrypting and decrypting relay
878
+traffic, doing SHA1 and AES-CTR operations.  But right now, all of
879
+this is done in the main thread!  It would be cool to split this
880
+across multiple cores instead.
881
+    </p>
882
+
883
+    <p>
884
+This won't be so easy though.  The code today is written to expect
885
+immediate results from its encryption operations, so you would need to
886
+do some pretty tricky refactoring in order get performance and
887
+correctness here.  Make sure you understand how circuit crypto is
888
+invoked today, and what the challenges are, before you apply for this
889
+one.
890
+    </p>
891
+
892
+    <p>
893
+For more information <a href="https://trac.torproject.org/projects/tor/ticket/1749">see its ticket</a>.
894
+    </p>
895
+    </li>
896
+
897
+    <a id="anonymousLocalCountStatistics"></a>
898
+    <li>
899
+    <b>Anonymous local count statistics</b>
900
+    <br>
901
+    Likely Mentors: <i>Nick (nickm), teor</i>
902
+    <br><br>
903
+    <p>
904
+There are some places in Tor where we count things (like distinct IPs)
905
+to later report anonymized statistics.  But if the local Tor instance
906
+were compromised, this data would be exposed.  There are statistical
907
+methods which insteasd allow us to record this data in a way that's
908
+already anonymous, before we ever summarize it.  Interested?
909
+    </p>
910
+
911
+    <p>
912
+For more information <a href="https://trac.torproject.org/projects/tor/ticket/7532">see its ticket</a>.
913
+    </p>
914
+    </li>
915
+
916
+    <a id="improveSocks5Variant"></a>
917
+    <li>
918
+    <b>Improved SOCKS5 variant</b>
919
+    <br>
920
+    Likely Mentors: <i>Nick (nickm), David Goulet (dgoulet)</i>
921
+    <br><br>
922
+    <p>
923
+In proposal 229, we describe a bunch of additional SOCKS extensions
924
+that Tor-aware applications could use to get more fine-grained control
925
+over how Tor handles their streams.  It would be cool to implement
926
+this!  If there's time remaining, you might want to add support to one
927
+or more applications.  Or maybe to torsocks?
928
+    </p>
929
+
930
+    <p>
931
+For more information <a href="https://trac.torproject.org/projects/tor/ticket/12456">see its ticket</a>.
932
+    </p>
933
+    </li>
934
+
935
+    <a id="hiddenServiceCryptoParallelism"></a>
936
+    <li>
937
+    <b>Hidden service crypto parallelism</b>
938
+    <br>
939
+    Likely Mentors: <i>Nick (nickm), David Goulet (dgoulet)</i>
940
+    <br><br>
941
+    <p>
942
+Hidden services, hidden service clients, hidden service directories,
943
+and introduction points all need to do a few public-key operations as
944
+they operate.  But right now, these operations are all done on the
945
+main thread.  It would be good to have these run across multiple cores.
946
+    </p>
947
+
948
+    <p>
949
+This could probably be done in a way similar to how we currently hand
950
+circuit extension handshakes in onion.c and cpuworker.c, but we'd need
951
+to extend the state machine for hidden services to add an additional
952
+state.  It could help hidden services operate much more efficiently.
953
+    </p>
954
+
955
+    <p>
956
+For more information <a href="https://trac.torproject.org/projects/tor/ticket/13738">see its ticket</a>.
957
+    </p>
958
+    </li>
959
+
960
+    <a id="supportAllDNS"></a>
961
+    <li>
962
+    <b>Support all kinds of DNS in Tor</b>
963
+    <br>
964
+    Likely Mentors: <i>Nick (nickm), George (asn)</i>
965
+    <br><br>
966
+    <p>
967
+Right now Tor can query for the kind of DNS information you'd find in
968
+A records, AAAA records, and PTR records.  It would be neat to be able
969
+to support more general DNS queries to allow things like MX loopups,
970
+DNSSEC lookups, and so on.  We have a design proposal (number 219) for
971
+this, but it might need some clean-up.
972
+    </p>
973
+
974
+    <p>
975
+For more information <a href="https://trac.torproject.org/projects/tor/ticket/7829">see its ticket</a>.
976
+    </p>
977
+    </li>
978
+
979
+    <a id="improveIpv6Support"></a>
980
+    <li>
981
+    <b>Improve IPv6 support</b>
982
+    <br>
983
+    Likely Mentors: <i>ahf, teor</i>
984
+    <br><br>
985
+    <p>
986
+Tor works over IPv6, but require some manual configuration.
987
+Clients and relays could automatically detect IPv6 availability,
988
+and configure themselves appropriately. Implementing a
989
+"happy eyeballs"-like algorithm is a challenge in an anonymity
990
+network: are you up for it?
991
+    </p>
992
+
993
+    <ul>
994
+      <li><a href="https://trac.torproject.org/projects/tor/ticket/6939">Missing IPv6 ORPort reachability check</a></li>
995
+      <li><a href="https://trac.torproject.org/projects/tor/ticket/4847">Bridges binding only to an IPv6 address doesn't work</a></li>
996
+      <li><a href="https://trac.torproject.org/projects/tor/ticket/5940">Figure out own IPv6 address</a></li>
997
+      <li><a href="https://trac.torproject.org/projects/tor/ticket/17011">Teach chutney to verify over IPv6</a></li>
998
+    </ul>
999
+
1000
+    <p>
1001
+For more information <a href="https://trac.torproject.org/projects/tor/ticket/17811">see its ticket</a>.
1002
+    </p>
1003
+    </li>
1004
+
838 1005
     <a id="feedbackExtension"></a>
839 1006
     <li>
840 1007
     <b>Feedback Extension for Tor Browser</b>