tor - Transit encryption and privacy out of the box

Age	Commit message (Collapse)	Author
2013-01-15	Clean up odds and ends	Roger Dingledine

2013-01-05	Make the = at the end of ntor-onion-key optional.	Nick Mathewson
	Makes bug 7869 more easily fixable if we ever choose to do so.
2013-01-03	Check all crypto_rand return values for ntor.	Nick Mathewson

2013-01-03	Use safe_mem_is_zero for checking curve25519 output for 0-ness	Nick Mathewson
	This should make the intent more explicit. Probably needless, though.
2013-01-02	Move curve25519 keypair type to src/common; give it functions	Nick Mathewson
	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.
2013-01-02	Refactor strong os-RNG into its own function	Nick Mathewson
	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.
2013-01-02	Add a wrapper around, and test and build support for, curve25519.	Nick Mathewson
	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.