1. 25 Sep, 2014 2 commits
  2. 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.
  3. 23 Mar, 2013 1 commit
  4. 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
  5. 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
      Fixes bug 8153; bugfix on where I did the fix for 7869.
  6. 31 Jan, 2013 1 commit
  7. 16 Jan, 2013 2 commits
  8. 15 Jan, 2013 1 commit
  9. 06 Jan, 2013 1 commit
  10. 03 Jan, 2013 2 commits
  11. 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.
    • 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.
    • 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.