1. 03 Jan, 2013 28 commits
  2. 02 Jan, 2013 12 commits
    • Nick Mathewson's avatar
      Split onion.[ch] into onion{,_fast,_tap}.[ch] · f7e590df
      Nick Mathewson authored
      I'm going to want a generic "onionskin" type and set of wrappers, and
      for that, it will be helpful to isolate the different circuit creation
      handshakes.  Now the original handshake is in onion_tap.[ch], the
      CREATE_FAST handshake is in onion_fast.[ch], and onion.[ch] now
      handles the onion queue.
      This commit does nothing but move code and adjust header files.
    • Nick Mathewson's avatar
      Wrangle curve25519 onion keys: generate, store, load, publish, republish · 5b3dd161
      Nick Mathewson authored
      Here we try to handle curve25519 onion keys from generating them,
      loading and storing them, publishing them in our descriptors, putting
      them in microdescriptors, and so on.
      This commit is untested and probably buggy like whoa
    • 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
    • Nick Mathewson's avatar
      Implementat the ntor handshake · cf4dd5fb
      Nick Mathewson authored
      The ntor handshake--described in proposal 216 and in a paper by
      Goldberg, Stebila, and Ustaoglu--gets us much better performance than
      our current approach.
    • 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.
    • Nick Mathewson's avatar
      curve25519-donna-c64: work on bigendian and alignment-happy systems · f0696602
      Nick Mathewson authored
      There was one place in curve25519-donna-c64 that was relying on
      unaligned access and relying on little-endian values.  This patch
      fixes that.
      I've sent Adam a pull request.
    • Nick Mathewson's avatar
    • Nick Mathewson's avatar
      Add fallback implementations for curve25519: curve25519_donna · 9c3c571c
      Nick Mathewson authored
      This is copied from Adam Langley's curve25519-donna package, as
      of commit 09427c9cab32075c06c3487aa01628030e1c5ae7.
    • Nick Mathewson's avatar
      Add a data-invariant linear-search map structure · cfab9f07
      Nick Mathewson authored
      I'm going to use this for looking op keys server-side for ntor.
    • Nick Mathewson's avatar
      Avoid spurious local-port warnings · ee418261
      Nick Mathewson authored
      Our old warn_nonlocal_client_ports() would give a bogus warning for
      every nonlocal port every time it parsed any ports at all.  So if it
      parsed a nonlocal socksport, it would complain that it had a nonlocal
      socksport...and then turn around and complain about the nonlocal
      socksport again, calling it a nonlocal transport or nonlocal dnsport,
      if it had any of those.
      Fixes bug 7836; bugfix on