| Age | Commit message (Collapse) | Author |
|---|
|
It looks like there was a compilation error for 6826 on some
platforms. Removing even more now-uncallable code to handle detecting
libevent versions before 1.3e.
Fixes bug 8012; bug not in any released Tor.
|
|
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.
|
|
|
|
(Pull on a thread and the whole sweater unravels.)
|
|
|
|
This won't actually break them any worse than they were broken before:
it just removes a set of warnings that nobody was actually seeing, I
hope.
Closes 6826
|
|
|
|
Conflicts:
src/or/or.h
srcwin32/orconfig.h
|
|
|
|
Fixes bug 7305.
|
|
|
|
|
|
Fixes bugs 7312 and 7310.
|
|
Fixes bug 7669
|
|
This is an automatically generated commit, from the following perl script,
run with the options "-w -i -p".
s/smartlist_string_num_isin/smartlist_contains_int_as_string/g;
s/smartlist_string_isin((?:_case)?)/smartlist_contains_string$1/g;
s/smartlist_digest_isin/smartlist_contains_digest/g;
s/smartlist_isin/smartlist_contains/g;
s/digestset_isin/digestset_contains/g;
|
|
Fixes ticket 6302
|
|
Fix for bug 7972
|
|
|
|
|
|
|
|
Fixes bug 7935. Reported by 'oftc_must_be_destroyed'.
|
|
Makes bug 7869 more easily fixable if we ever choose to do so.
|
|
Conflicts:
src/or/cpuworker.c
src/or/or.h
src/test/bench.c
|
|
|
|
This should make the intent more explicit. Probably needless, though.
|
|
|
|
This lets us give it compiler flags differing from the rest of
libor-crypto.a
|
|
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.
|
|
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.
|
|
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.
|
|
I'm going to use this for looking op keys server-side for ntor.
|
|
|
|
Spotted by coverity, bug 7816, bugfix on various versions.
|
|
|
|
|
|
|
|
|
|
|
|
This implements the server-side of proposal 198 by detecting when
clients lack the magic list of ciphersuites that indicates that
they're lying faking some ciphers they don't really have. When
clients lack this list, we can choose any cipher that we'd actually
like. The newly allowed ciphersuites are, currently, "All ECDHE-RSA
ciphers that openssl supports, except for ECDHE-RSA-RC4".
The code to detect the cipher list relies on on (ab)use of
SSL_set_session_secret_cb.
|
|
|
|
We already use this classification for deciding whether (as a server)
to do a v2/v3 handshake, and we're about to start using it for
deciding whether we can use good ciphersuites too.
|
|
This is less easy than you might think; we can't just look at the
client ciphers list, since openssl doesn't remember client ciphers if
it doesn't know about them. So we have to keep a list of the "v2"
ciphers, with the ones we don't know about removed.
|
|
|
|
We want to be saying fast_mem{cmp,eq,neq} when we're doing a
comparison that's allowed to exit early, or tor_mem{cmp,eq,neq} when
we need a data-invariant timing. Direct use of memcmp tends to imply
that we haven't thought about the issue.
|
|
Conflicts:
src/or/dns.c
|
|
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.
|
|
|
|
|
|
|
|
RFC1123 suggests that we should handle two-year times, and a full
range of time zones, and other stuff too. We don't.
|
