| Commit message (Collapse) | Author | Age | Files | Lines |
|\ |
|
| |
| |
| |
| |
| |
| | |
With no provider specified, Win32_CAPI_EntropySource::poll does not call
::CryptGenRandom and returns 0, leading to subsequent PRNG_Unseeded
exceptions.
|
| | |
|
| |
| |
| |
| | |
GH #656
|
| |
| |
| |
| | |
GH #656
|
| | |
|
| |
| |
| |
| | |
Some fixes for missing system_rng in ECIES and tests.
|
| |
| |
| |
| | |
Document that create_*_op is public but not for public consumption.
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Verification is deterministic and public, so really no RNG is ever needed.
Change provider handling - accepts "base", "openssl", or empty, otherwise
throws a Provider_Not_Found exception.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Instead the key types exposes operations like `create_encryption_op`
which will return the relevant operation if the algorithm supports it.
Changes pubkey.h interface, now RNG is passed at init time.
Blinder previous created its own RNG, now it takes it from app.
|
| |
| |
| |
| |
| | |
Now record layer only deals with an AEAD, and the weird complications
of CBC modes mostly hidden in tls_cbc.cpp
|
|\ \
| |/
|/| |
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | | |
Also changes Cert store interface to return shared_ptr, see GH #471
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | | |
See also GH #647
|
| | |/
| |/|
| | | |
Implement a backoff approach to opening the system RNG: if opening read-write fails, try to open read-only. This will allow the RNG to be used, but attempts to add entropy will fail. If opening as read-only also fails, only then throw an exception.
|
|\ \ \ |
|
| | |/
| |/|
| | |
| | |
| | |
| | | |
Compiling botan with disabled rc4 module fails in case of openssl w/o rc4...
Error:
./src/lib/prov/openssl/openssl_rc4.cpp:15:25: fatal error: openssl/rc4.h: No such file or directory
#include <openssl/rc4.h>
|
| |/
|/|
| |
| | |
Fixes GH #644
|
| | |
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TLS message parsing:
- CertificateVerify
- HelloVerify
- ClientHello (with extensions)
- ServerHello (with extensions)
- NewSessionTicket
- Alert
TLS message processing:
- HelloVerify
TLS Policy tests
Unit tests with TLS client authentication
Added test_throws method that checks the correct exception message.
|
| |
|
| |
|
|\ |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
The EtM and MtE codepaths had a lot of duplicated code.
Tests ok, also did manual testing against a few online machines
including the EtM test server at eid.vx4.net
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The Cipher_Mode::update API is more general than needed to just
support ciphers (this is due to it previously being an API of
Transform which before 8b85b780515 was Cipher_Mode's base class)
Define a less general interface `process` which either processes the
blocks in-place, producing exactly as much output as there was input,
or (SIV/CCM case) saves the entire message for processing in `finish`.
These two uses cover all current or anticipated cipher modes.
Leaves `update` for compatability with existing callers; all that is
needed is an inline function forwarding to `process`.
Removes the return type from `start` - in all cipher implementations,
this always returned an empty vector.
Adds BOTAN_ARG_CHECK macro; right now BOTAN_ASSERT is being used
for argument checking in some places, which is not right at all.
|
|\ \ \
| | | |
| | | |
| | | | |
Only partially resolves GH #619 see both issues for discussion.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
decoding.
If the client sent a signature_algorithms extension, we should negotiate a ciphersuite in
the shared union of the ciphersuite list and the extension, instead of ignoring it.
Found by Juraj Somorovsky GH #619
The TLS v1.2 spec says that clients should only send the signature_algorithms
extension in a hello for that version. Enforce that when decoding client hellos
to prevent this extension from confusing a v1.0 negotiation.
TLS v1.2 spec says ANON signature type is prohibited in the signature_algorithms extension
in the client hello. Prohibit it.
Reorder the TLS extensions in the client hello so there is no chance an empty extension is
the last extension in the list. Some implementations apparently reject such hellos, even
(perhaps especially) when they do not recognize the extension, this bug was mentioned on
the ietf-tls mailing list a while back.
|
|\ \ \ \
| |_|_|/
|/| | | |
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Self-issued certificates are certificates where subject_dn == issuer_dn,
but the signature is from a different key (ca key). Chains with such a
certificate could not be verified, because self-issued certificates
(1) would be taken for a self-signed certificate and
(2) find_issuing_cert() would find the same self-issued certificate
that we want to verify, generating a signature error during signature
verification.
To fix, we now first identify a certificate as self-signed only if
subject_dn == issuer_dn AND if we can verify the cert signature
with it's own key. Verification will bring some extra costs, but we
only do it once, in X509_Certificate's constructor. Second, we make
sure find_issuing_cert() does not return the very same certificate
we want to verify. This should be no problem, since path validation
currently does not seem to support validating a self-signed certificate.
|
|/ /
| |
| |
| |
| |
| | |
Mostly unused args and missing override notations.
Fix DH - load_check calls were commented out for debugging.
|
| | |
|
| |
| |
| |
| |
| | |
For block ciphers, stream ciphers, hashes, MACs, and cipher modes.
Cipher_Mode already had it, with a slightly different usage.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Various algorithms had an optimized implementation (for SSE2, AVX2, etc)
which was offered alongside the 'base' implementation. This is
admittedly very useful for testing, but it breaks user expectations in
bad ways. See GH #477 for background.
Now encrypting with `AES_128` (say) just runs whatever implementation
is best on the current processor/build.
|
| |
| |
| |
| |
| | |
If a non trival type was used, memory corruption could occur.
Original issue reported by Matthias Gierlings.
|
| | |
|
| | |
|
|\ \ |
|
| | | |
|