| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
BearSSL is much slower than Botan's builtins, and it is not commonly
included in distributions so doesn't even have the advantage of
ubiquity.
|
| |
|
|
| |
See #1822
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This commit implements the feedback from @securitykernel on the
PR and also changes the EC Group comparison to use the OID, akin
to OpenSSL. The EC Group comparison was needed before GH #1093
was merged, but now we can go use the OpenSSL variant.
|
| |
|
|
|
|
|
|
|
| |
BearSSL is an implementation of the SSL/TLS protocol in C aiming
to be correct and secure, small and highly portable. Thus making
it nicer to be included in a rather sparse bootloader. This commit
adds support for BearSSL's hash routines only, with more stuff
coming up in following commits. The goal is to be able to test
BearSSL using Botan's extensive testsuite.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
- Enables code for shake support
- Creating SHAKE hash function by name now allows to select output size
of 256 Bit for SHAKE128 and 512 Bit for SHAKE256.
- Adds *self-generated*, unverified test vectors for XMSS/SHAKE.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This required taking a global lock and doing a map lookup each
time an algorithm was requested (and so many times during a TLS
handshake).
|
| |
|
|
|
|
|
| |
I repent my use of global constructors.
I repent my use of global locks.
Hopefully I will never touch this code again.
:)
|
| |
|
|
|
|
|
|
|
|
| |
Kind of a copy and paste of Keccak, but only a single copy of the
permutation at least. Keccak depends on SHA-3 instead of the reverse,
so that SHA-3 can be enabled without also bringing in an unapproved
hash function.
Updates newhope code and removes API function newhope_hash which was
an unofficial SHA-3-256.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
explicit.
|
| | |
|
| |
|
|
| |
Only user-visible change is the removal of get_byte.h
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we were hanging on the type destructors to pull in
the relevant objects. However that fails in many simple cases
where the object is never deleted.
For every type involved in the algo registry add static create
and providers functions to access the algo registry. Modify
lookup.h to be inline and call those functions, and move
a few to sub-headers (eg, get_pbkdf going to pbkdf.h). So
accessing the registry involves going through the same file
that handles the initialization, so there is no way to end up
with missing objs.
|
|
|
The support problems from having static libraries not work in the
obvious way will be endless trouble. Instead have each set of
registrations tag along in a source file for the basic type, at the
cost of some extra ifdefs. On shared libs this is harmless -
everything is going into the shared object anyway. With static libs,
this means pulling in a single block cipher pulls in the text of all
the them. But that's still strictly better than the amalgamation
(which is really pulling in everything), and it works (unlike status quo).
|
