| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
|\ |
|
| |
| |
| |
| | |
Blamed VC miscompilation but actually a bug on my part.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
Miscompiles on x86-32, even with VS2017
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
This work was sponsored by Ribose Inc
|
| |
| |
| |
| | |
This work was sponsored by Ribose Inc
|
| |
| |
| |
| | |
[ci skip]
|
| |
| |
| |
| | |
Otherwise we just SIGSEGV.
|
| | |
|
|/
|
|
|
|
|
| |
function declaration is already hidden, fix some param names in doxygen
comments, fixes #1067
This work was sponsored by Ribose Inc (@riboseinc).
|
| |
|
|
|
|
|
| |
this the compress/uncompress methods may produce corrupted files on
Windows.
|
|
|
|
| |
Instead of hardcoding which ecc groups to test in each alg.
|
|
|
|
| |
Constify some member functions
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When renegotiating the client checks that the server hasn't
changed its mind about supporting the renegotiation extension
(this is a likely indicator of an attack).
However due to a typo the client was actually comparing the
value in the client hello of the first handshake against the
server hello in the renegotiation handshake. Since Botan always
sends the renegotiation extension, this would cause the check to
fail when renegotiating with an old server that doesn't support
the renegotiation extension.
Reported on mailing list by Falko Strenzke. Tested patch against
OpenSSL 0.9.8k
|
| |
|
|
|
|
|
|
|
|
| |
In simple mode (no salt) with an empty password the input buffer
is empty.
Add a check that salt is not empty if iterations > 1 since PGP
only has simple, salted, and iterated+salted modes.
|
|
|
|
|
|
| |
Made a try at implementing it but its a huge pain due to the
combination of the iteration count being the byte count and that
we have to end on exactly an encodable iteration count.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was removed somewhere along the line in 1.11, with the logic
that it is a funky PGP-specific scheme and (quoting the commit
that removed it) "not really useful outside of a full PGP implementation".
This assumed that the PGP implementation would be in Botan itself, but
PGP is implemented in https://github.com/evpo/EncryptPad/ (which is
a PGP implementation using 1.10), and RNP (https://github.com/riboseinc/rnp)
would like to use it also.
This work was sponsored by Ribose Inc (@riboseinc).
|
| |
|
|
|
|
|
|
| |
Add some #ifdef LIBRESSL_VERSION_NUMBER in addition to the
OPENSSL_VERSION_NUMBER switch. Narrow down API compatiblity between
LibreSSL and OpenSSL version in docs.
|
|\ |
|
| | |
|
| |
| |
| |
| |
| | |
They don't understand unique_ptr<Derived> to unique_ptr<Base> without help
https://stackoverflow.com/questions/22018115/converting-stdunique-ptrderived-to-stdunique-ptrbase
|
| |
| |
| |
| | |
See GH #1037
|
|\ \ |
|
| | | |
|
| | | |
|
|\ \ \ |
|
| | | |
| | | |
| | | |
| | | | |
This allows all tests to run even if no RNG type enabled in the build
|
|\ \ \ \
| |_|_|/
|/| | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Works everywhere but Apple Clang. Could handle this with a hack
to configure but running ARMv8 in 32-bit mode is rare and suboptimal,
and it would be better to deal with this using compile-time feature
detection.
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fix for new define syntax, remove old style casts.
Add some randomly generated longer SHA-256 vectors, previously had
precisely zero multiblock tests.
|
| | | |
| | | |
| | | |
| | | | |
Based on patch from Jeffrey Walton in GH #841
|
| |/ /
| | |
| | |
| | |
| | |
| | | |
Based on patch from Jeffrey Walton in GH #840
Only tested in qemu so far.
|
|\ \ \
| |/ /
|/| | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fixes GH #991
The problem with the current implementation of the chain validation code is that is runs from the end certificate to the trust cert.
@securitykernel and me tried to fix the pathLenConstraint validation within this reverse loop but we were not sure if we missed some edge cases.
So we felt safer to use the algorithm listed in RFC 5280 which executes from the top to the bottom. It's probably best to rewrite the code to use the whole algorithm from RFC 5280, i.e. validating the chain from the trust to the end cert.
Additionally, we wrote some tests including the one that raised this issue initially.
|