| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
| |
It allows us more flexibility on the backend if the user needs to
specify the key and IV at setup time.
|
| |
|
|
| |
We never use it, and it would be a stupid thing if we started using it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes bug 4893.
These changes are pure mechanical, and were generated with this
perl script:
/usr/bin/perl -w -i.bak -p
s/crypto_pk_env_t/crypto_pk_t/g;
s/crypto_dh_env_t/crypto_dh_t/g;
s/crypto_cipher_env_t/crypto_cipher_t/g;
s/crypto_digest_env_t/crypto_digest_t/g;
s/aes_free_cipher/aes_cipher_free/g;
s/crypto_free_cipher_env/crypto_cipher_free/g;
s/crypto_free_digest_env/crypto_digest_free/g;
s/crypto_free_pk_env/crypto_pk_free/g;
s/_crypto_dh_env_get_dh/_crypto_dh_get_dh/g;
s/_crypto_new_pk_env_rsa/_crypto_new_pk_from_rsa/g;
s/_crypto_pk_env_get_evp_pkey/_crypto_pk_get_evp_pkey/g;
s/_crypto_pk_env_get_rsa/_crypto_pk_get_rsa/g;
s/crypto_new_cipher_env/crypto_cipher_new/g;
s/crypto_new_digest_env/crypto_digest_new/g;
s/crypto_new_digest256_env/crypto_digest256_new/g;
s/crypto_new_pk_env/crypto_pk_new/g;
s/crypto_create_crypto_env/crypto_cipher_new/g;
s/connection_create_listener/connection_listener_new/g;
s/smartlist_create/smartlist_new/g;
s/transport_create/transport_new/g;
|
| |
|
|
|
|
|
|
|
|
|
| |
To solve bug 4779, we want to avoid OpenSSL 1.0.0's counter mode.
But Fedora (and maybe others) lie about the actual OpenSSL version,
so we can't trust the header to tell us if it's safe.
Instead, let's do a run-time test to see whether it's safe, and if
not, use our built-in version.
fermenthor contributed a pretty essential fixup to this patch. Thanks!
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
When we added the check for key size, we required that the keys be
128 bytes. But RSA_size (which defers to BN_num_bytes) will return
128 for keys of length 1017..1024. This patch adds a new
crypto_pk_num_bits() that returns the actual number of significant
bits in the modulus, and uses that to enforce key sizes.
Also, credit the original bug3318 in the changes file.
|
| |
|
|
|
|
|
|
|
|
|
| |
Most instances were dead code; for those, I removed the assignments.
Some were pieces of info we don't currently plan to use, but which
we might in the future. For those, I added an explicit cast-to-void
to indicate that we know that the thing's unused. Finally, one was
a case where we were testing the wrong variable in a unit test.
That one I fixed.
This resolves bug 3208.
|
| | |
|
| |
|
|
|
|
| |
Our regular DH parameters that we use for circuit and rendezvous
crypto are unchanged. This is yet another small step on the path of
protocol fingerprinting resistance.
|
| |
|
|
|
|
|
|
|
| |
Conflicts:
src/or/config.c
src/or/networkstatus.c
src/or/rendcommon.c
src/or/routerparse.c
src/or/test.c
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
See task 1114. The most plausible explanation for someone sending us weak
DH keys is that they experiment with their Tor code or implement a new Tor
client. Usually, we don't care about such events, especially not on warn
level. If we really care about someone not following the Tor protocol, we
can set ProtocolWarnings to 1.
|
| | |
|
| |
|
|
|
| |
The earlier fix would only handle the success case. In the failing
case, test_mem_op does a goto done, which would leave the leak leaking.
|
| |
|