| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Also simplify crypto_common_digests() to have no loop.
|
|
They are no longer "all" digests, but only the "common" digests.
Part of 17795.
This is an automated patch I made with a couple of perl one-liners:
perl -i -pe 's/crypto_digest_all/crypto_common_digests/g;' src/*/*.[ch]
perl -i -pe 's/\bdigests_t\b/common_digests_t/g;' src/*/*.[ch]
|
|
|
|
Also tested with 1.0.0t and 1.0.2f.
Closes ticket 19784.
Closes most of 17921. (Still need to make some tests pass.)
|
|
|
|
Part of 16794.
|
|
Part of #16794
|
|
|
|
This creates a random 100 KiB buffer, and incrementally hashes
(SHA3-512) between 1 and 5 * Rate bytes in a loop, comparing the running
digest with the equivalent one shot call from the start of the buffer.
|
|
This is an eXtendable-Output Function with the following claimed
security strengths against *all* adversaries:
Collision: min(d/2, 256)
Preimage: >= min(d, 256)
2nd Preimage: min(d, 256)
where d is the amount of output used, in bits.
|
|
* DIGEST_SHA3_[256,512] added as supported algorithms, which do
exactly what is said on the tin.
* test/bench now benchmarks all of the supported digest algorithms,
so it's possible to see just how slow SHA-3 is, though the message
sizes could probably use tweaking since this is very dependent on
the message size vs the SHA-3 rate.
|
|
Bugfix on a tor version before the refactoring in git commit
cea12251995d (23 Sep 2009). Patch by "teor".
|
|
|
|
Nobody likes a stack overflow, even in unit tests.
Closes 17699; but not in any released tor.
|
|
Check that crypto_rand doesn't return all zeroes, identical values,
or incrementing values (OpenSSL's rand_predictable feature).
|
|
|
|
|
|
The runtime sanity checking is slightly different from the optimized
basepoint stuff in that it uses a given implementation's self tests if
available, and checks if signing/verification works with a test vector
from the IETF EdDSA draft.
The unit tests include a new testcase that will fuzz donna against ref0,
including the blinding and curve25519 key conversion routines. If this
is something that should be done at runtime (No?), the code can be
stolen from there.
Note: Integrating batch verification is not done yet.
|
|
Integration work scavanged from nickm's `ticket8897_9663_v2` branch,
with minor modifications. Tor will still sanity check the output but
now also attempts to catch extreme breakage by spot checking the
optimized implementation vs known values from the NaCl documentation.
Implements feature 9663.
|
|
Fixed numerous conflicts, and ported code to use new base64 api.
|
|
Now that we have ed25519 keys, we can sign descriptors with them
and check those signatures as documented in proposal 220.
|
|
Conflicts:
src/test/testing_common.c
|
|
It needed an argument before because it wasn't safe to call
RAND_poll() on openssl 0.9.8c if you had already opened more fds
than would fit in fd_set.
|
|
These commands allow for the creation and management of ephemeral
Onion ("Hidden") services that are either bound to the lifetime of
the originating control connection, or optionally the lifetime of
the tor instance.
Implements #6411.
|
|
|
|
|
|
|
|
|
|
This can run in parallel with the faster ones and the other tests.
|
|
|
|
|
|
|
|
Part of fix for 13172
|
|
Because in 95 years, we or our successors will surely care about
enforcing the BSD license terms on this code. Right?
|
|
By now, support in the network is widespread and it's time to require
more modern crypto on all Tor instances, whether they're clients or
servers. By doing this early in 0.2.6, we can be sure that at some point
all clients will have reasonable support.
|
|
|
|
Ensure test & bench code that references curve25519 is disabled by the
appropriate macros. tor now builds with and without --disable-curve25519.
|
|
Conflicts:
src/common/include.am
src/ext/README
|
|
Also, use it to generate test vectors, and add those test vectors
to test_crypto.c
This is based on ed25519.py from the ed25519 webpage; the kludgy hacks
are my own.
|
|
This implementation allows somebody to add a blinding factor to a
secret key, and a corresponding blinding factor to the public key.
Robert Ransom came up with this idea, I believe. Nick Hopper proved a
scheme like this secure. The bugs are my own.
|
|
For proposal 228, we need to cross-certify our identity with our
curve25519 key, so that we can prove at descriptor-generation time
that we own that key. But how can we sign something with a key that
is only for doing Diffie-Hellman? By converting it to the
corresponding ed25519 point.
See the ALL-CAPS warning in the documentation. According to djb
(IIUC), it is safe to use these keys in the ways that ntor and prop228
are using them, but it might not be safe if we start providing crazy
oracle access.
(Unit tests included. What kind of a monster do you take me for?)
|
|
|
|
This will be needed/helpful for the key blinding of prop224, I
believe.
|
|
Taken from earlier ed25519 branch based on floodyberry's
ed25519-donna. Tweaked so that it applies to ref10 instead.
|
|
Conflicts:
src/test/test_crypto.c
|
|
|
|
Suggested by yawning.
|
|
Use HKDF for RFC2440 s2k only.
|
