tor - [no description]

	Commit message (Collapse)	Author	Age
*	Explain CURVE25519_ENABLED: closes 9774	Nick Mathewson	2014-02-07
\|
*	Completely refactor how FILENAME_PRIVATE works	Nick Mathewson	2013-07-10
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	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.
*	Fix compilation with --disable-curve25519 option	Nick Mathewson	2013-02-04
\| \| \| \| \| \| \| \| \|	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.
*	Update the copyright date to 201.	Nick Mathewson	2013-01-16
\|
*	Make the = at the end of ntor-onion-key optional.	Nick Mathewson	2013-01-05
\| \| \| \|	Makes bug 7869 more easily fixable if we ever choose to do so.
*	Check all crypto_rand return values for ntor.	Nick Mathewson	2013-01-03
\|
*	Move curve25519 keypair type to src/common; give it functions	Nick Mathewson	2013-01-02
\| \| \| \| \| \|	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.
*	Add a wrapper around, and test and build support for, curve25519.	Nick Mathewson	2013-01-02
	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.