| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Fixes #1883
|
| |
|
|
|
|
|
|
|
| |
Otherwise the alignment tests can fail. OSS-Fuzz 12412
And also free the pages on exit otherwise OSS-Fuzz detects it
as a leak. OSS-Fuzz 12413
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Basically, test that it works. Accepts a sequence of alloc+free
operations and verify that each pointer returned does not overlap with
any other outstanding allocation, that the memory returned is zeroed,
and that alignment is respected.
Intended for testing #1800 but no reason not to land this first.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The test_fuzzers.py script is very slow especially on CI. Add a mode
to the test fuzzers where it will accept many files on the command
line and test each of them in turn. This is 100s of times faster,
as it avoids all overhead from fork/exec.
It has the downside that you can't tell which input caused a crash, so
retain the old mode with --one-at-a-time option for debugging work.
|
|
|
|
|
|
|
|
|
| |
Originally wrote it for div-by-word but that ends up requiring a dword
type which we don't always have. And uint8_t covers the most important
cases of n = 10 and n = 58 (whenever I get around to writing base58).
We could portably support up to div-by-uint32, but I don't think we need it.
Nicely for n = 10, this is actually faster than the variable time division.
|
|
|
|
|
|
|
|
| |
It is stupid and slow (~50-100x slower than variable time version) but
still useful for protecting critical algorithms.
Not currently used, waiting for OSS-Fuzz to test it for a while before
we commit to it.
|
|
|
|
|
|
|
| |
Introduced in b13c0cc8590199d, it could only trigger if the block size
was more than 256 bytes. In that case an invalid padding could be accepted.
OSS-Fuzz 11608 (https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11608)
|
| |
|
| |
|
|
|
|
|
|
| |
The reference version of 1and0 padding would crash on an all-zero input.
OSS-Fuzz 10628
|
|
|
|
| |
This tests the delim scanning section which must be const time.
|
|
|
|
|
|
|
| |
Both PKCS7 and X9.23 padding modes did not examine the first byte
of the purported padding if the padding took an entire block. So
for example for a 64-bit cipher, PKCS7 would accept XX08080808080808
as a valid padding for any byte value.
|
|
|
|
|
|
| |
-x*n % n would reduce to n instead of zero.
Also some small optimizations and cleanups.
|
| |
|
| |
|
|
|
|
|
| |
Currently OSS-Fuzz stops cold at receiving the certificate message
since the odds of libFuzzer forging an RSA signature are not high.
|
|
|
|
|
|
| |
Needed for OSS-Fuzz (OOMing a lot) and maybe very occasionally
useful in some weird application that has to deal with 100s of
different curves.
|
|
|
|
|
|
|
|
|
| |
Adds PointGFp::force_affine(), ::add_affine(), and ::is_affine()
Use a (very simple) technique for base point precomputations.
Stick with fixed window for variable point inputs.
Scalar blinding is now always enabled
|
|
|
|
|
| |
Now binary ext gcd algorithm has an exposed API so no need to
duplicate the code here.
|
|
|
|
| |
This runs into the same weird UbSan issue as in #1370
|
|
|
|
|
|
|
|
|
|
| |
OSS-Fuzz 6570 flagged an issue with slow modular exponentation.
It turned out the problem was not in the library version but the
simple square-and-multiply algorithm. Computing g^x % p with all
three integers being dense (high Hamming weight) numbers took about
1.5 seconds on a fast machine with almost all of the time taken
by the Barrett reductions. With these changes, same testcase
now takes only a tiny fraction of a second.
|
|
|
|
|
| |
Previously it used a hardcoded (random) prime, but accepting all
three inputs allows much better coverage of corner cases.
|
| |
|
| |
|
|
|
|
| |
No shared state
|
|
|
|
| |
Hide CurveGFp with an eye for eventual removal
|
| |
|
|
|
|
|
|
| |
Now the base class ASN1_Formatter parses the data and calls virtuals
to format. This allows custom formatting, or in the case of the fuzzer
skipping the overhead of formatting entirely.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
ISO C++ reserves names with double underscores in them
Closes #512
|
|
|
|
|
| |
If we ever output something to the terminal it should be because
we are crashing.
|
|
|
|
|
|
| |
For the fuzzers, builds an object and then links in a second step,
because we need that to link the fuzzer binaries for LLVM. (Clang
will emit bitcode for us, but doesn't want to link it.)
|
|
|