| Commit message (Collapse) | Author | Age |
|
|
|
|
| |
(It's nice to know what we were about to rename before we died from
renaming it.)
|
|
|
|
|
|
| |
Most of these are simple. The only nontrivial part is that our
pattern for using ENUM_BF was confusing doxygen by making declarations
that didn't look like declarations.
|
|
|
|
|
| |
Previously we had set up all the infrastructure to avoid calling it
after the first time, but didn't actually use it.
|
| |
|
|
|
|
| |
Implements #10884.
|
|
|
|
| |
This completes our conversion to using siphash for our hash functions.
|
|
|
|
|
|
|
|
|
| |
It's increasingly apparent that we want to make sure we initialize our
PRNG nice and early, or else OpenSSL will do it for us. (OpenSSL
doesn't do _too_ bad a job, but it's nice to do it ourselves.)
We'll also need this for making sure we initialize the siphash key
before we do any hashes.
|
|
|
|
| |
sed -i 's/BN_free/BN_clear_free/g'
|
|\
| |
| |
| |
| | |
Conflicts:
src/common/crypto.c
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This fixes bug 10402, where the rdrand engine would use the rdrand
instruction, not as an additional entropy source, but as a replacement
for the entire userspace PRNG. That's obviously stupid: even if you
don't think that RDRAND is a likely security risk, the right response
to an alleged new alleged entropy source is never to throw away all
previously used entropy sources.
Thanks to coderman and rl1987 for diagnosing and tracking this down.
|
| |
| |
| |
| |
| |
| |
| | |
It's not nice to talk about NID_aes_{128,256}_{ctr,gcm} when they
don't exist.
Fix on 84458b79a78ea7e26820bf0; bug not in any released Tor.
|
| |
| |
| |
| | |
Fixes ticket 10043; patch from Joshua Datko.
|
|\ \
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/or/config.c
src/or/main.c
|
| | | |
|
| | |
| | |
| | |
| | | |
of libevent, openssl and zlib. Partially implements #6384.
|
|\ \ \
| |/ /
|/| |
| | |
| | | |
Conflicts:
src/common/sandbox.c
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
Incidentally, this business here where I make crypto_rand mockable:
this is exactly the kind of thing that would make me never want to
include test-support stuff in production builds.
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
See #8792
|
|\|
| |
| |
| |
| | |
Conflicts:
src/common/crypto.c
|
| | |
|
| |\
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/or/dirserv.c
src/or/dirserv.h
src/test/test_dir.c
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
Now we can compute the hash and signature of a dirobj before
concatenating the smartlist, and we don't need to play silly games
with sigbuf and realloc any more.
|
|\| | |
|
| |\ \ |
|
| | |/
| | |
| | |
| | | |
Fixes ticket 6673.
|
|\| |
| | |
| | |
| | |
| | | |
Conflicts:
src/or/routerlist.c
|
| | | |
|
| |/ |
|
| | |
|
|/
|
|
|
| |
(We're not adding any new SHA1 instances in our protocols, so this
should never actually be needed.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need a weak RNG in a couple of places where the strong RNG is
both needless and too slow. We had been using the weak RNG from our
platform's libc implementation, but that was problematic (because
many platforms have exceptionally horrible weak RNGs -- like, ones
that only return values between 0 and SHORT_MAX) and because we were
using it in a way that was wrong for LCG-based weak RNGs. (We were
counting on the low bits of the LCG output to be as random as the
high ones, which isn't true.)
This patch adds a separate type for a weak RNG, adds an LCG
implementation for it, and uses that exclusively where we had been
using the platform weak RNG.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is meant to avoid conflict with the built-in log() function in
math.h. It resolves ticket 7599. First reported by dhill.
This was generated with the following perl script:
#!/usr/bin/perl -w -i -p
s/\blog\(LOG_(ERR|WARN|NOTICE|INFO|DEBUG)\s*,\s*/log_\L$1\(/g;
s/\blog\(/tor_log\(/g;
|
|
|
|
|
|
|
|
| |
Patch from onizuka generated with
find ./ -type f -perm -u+rw -exec sed -ri 's/(Base)-(16|32|64)/\1\2/gi' {} \;
Fixes issue 6875 on Tor.
|
|\
| |
| |
| |
| |
| | |
Conflicts:
src/or/or.h
srcwin32/orconfig.h
|
| |
| |
| |
| | |
Fixes bug 7305.
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/or/cpuworker.c
src/or/or.h
src/test/bench.c
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is a customizable extract-and-expand HMAC-KDF for deriving keys.
It derives from RFC5869, which derives its rationale from Krawczyk,
H., "Cryptographic Extraction and Key Derivation: The HKDF Scheme",
Proceedings of CRYPTO 2010, 2010, <http://eprint.iacr.org/2010/264>.
I'm also renaming the existing KDF, now that Tor has two of them.
This is the key derivation scheme specified in ntor.
There are also unit tests.
|
| |/ |
|
|/ |
|
|
|
|
| |
Affects comments only. For ticket 6849.
|
|\
| |
| |
| |
| |
| | |
Conflicts:
src/common/crypto.c
src/or/rendservice.c
|