| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
| |
Apparently some compilers like to eliminate memset() operations on
data that's about to go out-of-scope. I've gone with the safest
possible replacement, which might be a bit slow. I don't think this
is critical path in any way that will affect performance, but if it
is, we can work on that in 0.2.4.
Fixes bug 7352.
|
| | |
|
| |
|
|
|
|
| |
We never use it, so having it around is pointless.
Suggested by Sebastian
|
| |
|
|
|
| |
It allows us more flexibility on the backend if the user needs to
specify the key and IV at setup time.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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;
|
| |
|
|
|
| |
It's a pain to convert 0x0090813f to and from 0.9.8s-release on the
fly, so these macros should help.
|
| | |
|
| | |
|
| |
|
|
|
| |
- Make check-spaces happy.
- Remove a stray header from crypto.h
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Instead of passing the DynamicPrimes configuration option to
crypto_global_init(), generate and set a new TLS DH prime when we read
the torrc.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This commit copies parts of Jake's
f3bb6846975193d9a6649c31f94bda47e4014070 commit verbatim to the
current master.
|
| | |
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |\| |
|
| | |\
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fixed trivial conflict due to headers moving into their own .h files
from or.h.
Conflicts:
src/or/or.h
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Rename crypto_pk_check_key_public_exponent to crypto_pk_public_exponent_ok:
it's nice to name predicates s.t. you can tell how to interpret true
and false.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
(Backport from 0.2.2's 5ed73e3807d90dd0a3)
|
| |\| | |
|
| | | | |
|
| |\| | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
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/routerparse.c
src/or/test.c
|
| | | |\ |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
I am not at all sure that it is possible to trigger a bug here,
but better safe than sorry.
|
| |\| | | |
|
| | |\| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
src/or/config.c
src/or/networkstatus.c
src/or/rendcommon.c
src/or/routerparse.c
src/or/test.c
|
| | | |/
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
mistake again
Our public key functions assumed that they were always writing into a
large enough buffer. In one case, they weren't.
(Incorporates fixes from sebastian)
|
| |\| | |
|
| | |\|
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/common/test.h
src/or/test.c
|
| | | | |
|
| |/ /
| |
| |
| | |
Thanks to Sebastian for his code-review of the bufferevents patch series.x
|
| | | |
|
| |\|
| |
| |
| |
| |
| | |
Conflicts:
src/common/test.h
src/or/test.c
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
In 5e4d53d535a3cc9903250b3df0caa829f1c5e4bf we made it so that
crypto_cipher_set_key cannot fail. The call will now
always succeed, to returning a boolean for success/failure makes
no sense.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This patch introduces a new type called document_signature_t to represent the
signature of a consensus document. Now, each consensus document can have up
to one document signature per voter per digest algorithm. Also, each
detached-signatures document can have up to one signature per <voter,
algorithm, flavor>.
|
| | | |
|