1. 06 Apr, 2018 1 commit
  2. 03 Feb, 2018 1 commit
  3. 28 Sep, 2017 1 commit
  4. 15 Sep, 2017 1 commit
  5. 15 Mar, 2017 1 commit
  6. 11 Jan, 2017 1 commit
  7. 17 Oct, 2016 2 commits
    • Nick Mathewson's avatar
      Fix a syntax problem · f3174428
      Nick Mathewson authored
      f3174428
    • Nick Mathewson's avatar
      Write a bunch of module documentation. · aae034d1
      Nick Mathewson authored
      This commit adds or improves the module-level documenation for:
      
        buffers.c circuitstats.c command.c connection_edge.c control.c
        cpuworker.c crypto_curve25519.c crypto_curve25519.h
        crypto_ed25519.c crypto_format.c dircollate.c dirserv.c dns.c
        dns_structs.h fp_pair.c geoip.c hibernate.c keypin.c ntmain.c
        onion.c onion_fast.c onion_ntor.c onion_tap.c periodic.c
        protover.c protover.h reasons.c rephist.c replaycache.c
        routerlist.c routerparse.c routerset.c statefile.c status.c
        tor_main.c workqueue.c
      
      In particular, I've tried to explain (for each documented module)
      what each module does, what's in it, what the big idea is, why it
      belongs in Tor, and who calls it.  In a few cases, I've added TODO
      notes about refactoring opportunities.
      
      I've also renamed an argument, and fixed a few DOCDOC comments.
      aae034d1
  8. 16 May, 2016 1 commit
  9. 26 Mar, 2016 1 commit
  10. 27 Feb, 2016 2 commits
  11. 08 Dec, 2015 1 commit
  12. 26 Nov, 2015 1 commit
  13. 31 Jul, 2015 1 commit
    • Nick Mathewson's avatar
      Move formatting functions around. · 347fe449
      Nick Mathewson authored
      The base64 and base32 functions used to be in crypto.c;
      crypto_format.h had no header; some general-purpose functions were in
      crypto_curve25519.c.
      
      This patch makes a {crypto,util}_format.[ch], and puts more functions
      there.  Small modules are beautiful!
      347fe449
  14. 16 Jul, 2015 1 commit
  15. 14 Jul, 2015 1 commit
  16. 06 Jul, 2015 1 commit
    • Yawning Angel's avatar
      Integrate the accelerated Curve25519 scalar basemult. · f079c277
      Yawning Angel authored
      Integration work scavanged from nickm's `ticket8897_9663_v2` branch,
      with minor modifications.  Tor will still sanity check the output but
      now also attempts to catch extreme breakage by spot checking the
      optimized implementation vs known values from the NaCl documentation.
      
      Implements feature 9663.
      f079c277
  17. 02 Jan, 2015 1 commit
  18. 28 Oct, 2014 1 commit
  19. 25 Sep, 2014 5 commits
  20. 10 Jul, 2013 1 commit
    • Nick Mathewson's avatar
      Completely refactor how FILENAME_PRIVATE works · a3e0a87d
      Nick Mathewson authored
      We previously used FILENAME_PRIVATE identifiers mostly for
      identifiers exposed only to the unit tests... but also for
      identifiers exposed to the benchmarker, and sometimes for
      identifiers exposed to a similar module, and occasionally for no
      really good reason at all.
      
      Now, we use FILENAME_PRIVATE identifiers for identifiers shared by
      Tor and the unit tests.  They should be defined static when we
      aren't building the unit test, and globally visible otherwise. (The
      STATIC macro will keep us honest here.)
      
      For identifiers used only by the unit tests and never by Tor at all,
      on the other hand, we wrap them in #ifdef TOR_UNIT_TESTS.
      
      This is not the motivating use case for the split test/non-test
      build system; it's just a test example to see how it works, and to
      take a chance to clean up the code a little.
      a3e0a87d
  21. 23 Mar, 2013 1 commit
  22. 07 Feb, 2013 1 commit
    • Nick Mathewson's avatar
      Tolerate curve25519 backends where the high bit of the pk isn't ignored · 266419d2
      Nick Mathewson authored
      Right now, all our curve25519 backends ignore the high bit of the
      public key. But possibly, others could treat the high bit of the
      public key as encoding out-of-bounds values, or as something to be
      preserved. This could be used to distinguish clients with different
      backends, at the cost of killing a circuit.
      
      As a workaround, let's just clear the high bit of each public key
      indiscriminately before we use it. Fix for bug 8121, reported by
      rransom. Bugfix on 0.2.4.8-alpha.
      266419d2
  23. 04 Feb, 2013 1 commit
    • Nick Mathewson's avatar
      Fix compilation with --disable-curve25519 option · 5ea9a90d
      Nick Mathewson authored
      The fix is to move the two functions to format/parse base64
      curve25519 public keys into a new "crypto_format.c" file.  I could
      have put them in crypto.c, but that's a big file worth splitting
      anyway.
      
      Fixes bug 8153; bugfix on 0.2.4.8-alpha where I did the fix for 7869.
      5ea9a90d
  24. 31 Jan, 2013 1 commit
  25. 16 Jan, 2013 2 commits
  26. 15 Jan, 2013 1 commit
  27. 06 Jan, 2013 1 commit
  28. 03 Jan, 2013 2 commits
  29. 02 Jan, 2013 3 commits
    • Nick Mathewson's avatar
      Move curve25519 keypair type to src/common; give it functions · 6c883bc6
      Nick Mathewson authored
      This patch moves curve25519_keypair_t from src/or/onion_ntor.h to
      src/common/crypto_curve25519.h, and adds new functions to generate,
      load, and store keypairs.
      6c883bc6
    • Nick Mathewson's avatar
      Refactor strong os-RNG into its own function · 25c05cb7
      Nick Mathewson authored
      Previously, we only used the strong OS entropy source as part of
      seeding OpenSSL's RNG.  But with curve25519, we'll have occasion to
      want to generate some keys using extremely-good entopy, as well as the
      means to do so.  So let's!
      
      This patch refactors the OS-entropy wrapper into its own
      crypto_strongest_rand() function, and makes our new
      curve25519_secret_key_generate function try it as appropriate.
      25c05cb7
    • Nick Mathewson's avatar
      Add a wrapper around, and test and build support for, curve25519. · 89ec5848
      Nick Mathewson authored
      We want to use donna-c64 when we have a GCC with support for
      64x64->uint128_t multiplying.  If not, we want to use libnacl if we
      can, unless it's giving us the unsafe "ref" implementation.  And if
      that isn't going to work, we'd like to use the
      portable-and-safe-but-slow 32-bit "donna" implementation.
      
      We might need more library searching for the correct libnacl,
      especially once the next libnacl release is out -- it's likely to have
      bunches of better curve25519 implementations.
      
      I also define a set of curve25519 wrapper functions, though it really
      shouldn't be necessary.
      
      We should eventually make the -donna*.c files get build with
      -fomit-frame-pointer, since that can make a difference.
      89ec5848