The slh_dsa fuzzer predicts failure in EVP_message_sign_init in the
event we pass a context_string param of more than 255 bytes. That makes
for an accurate prediction, but only if we actually create the param.
augment the setting of exepct_rc_init to be determined not only by our
allocation of a > 255 byte message, but also on selector bit 1, which
determines if we create the parameter at all.
Fixes https://oss-fuzz.com/testcase-detail/4807793999937536
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/26884)
Current preforms the following operations
1) Generates arbitrary key pairs
2) Generates key pairs with parameters (both correct and incorrect)
based on fuzzer input buffer
3) Exports and re-imports keys, confirming validity
4) Preforms Sign and Verify operations with optional parameters based on
fuzzer input buffer
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26708)
Add an initial version of an ML-DSA fuzzer. Exercises various ML-DSA
appropriate APIs. Currently it is able to randomly:
1. Attempt to create raw public private keys of various valid and invalid sizes
2. Generate legitimate keys of various sizes using the keygen api
3. Perform sign/verify operations using real generated keys
4. Perform digest sign/verify operations using real generated keys
5. Do an export and import of a key using todata/fromdata
6. Do a comparison of two equal and unequal keys
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26685)
Add an inital version of an ML-KEM fuzzer. Exercises various ML-KEM
appropriate apis, as a fuzzer does. Currently it is able to randomly:
1) Attempt to create raw public private keys of various valid and
invalid sizes
2) Generate legitimate keys of various sizes using the keygen api
3) Preform encap/decap operations using real generated keys
4) Do a shared secret derivation using 2 keys
5) Do an export and import of a key using todata/fromdata
6) Do a comparison of two equal and unequal keys
Its not much to start, but it should be fairly extensible
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26657)
Add full key matching to hashtable
the idea is that on a hash value match we do a full memory comparison of
the unhashed key to validate that its actually the key we're looking for
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24504)
Sub-OIDs for {iso(1) identified-organization(3) dod(6) internet(1)
private(4) enterprise(1) 45605} are recorded in the document "Wi-SUN
Assigned Value Registry" (WAVR).
OID id-on-hardwareModule is defined in RFC 4108.
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23428)
Move the switch to print a distinguished name inside the
switch by the printed attribute type, otherwise a malformed
attribute will cause a crash.
Updated the fuzz corpora with the testcase
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
(Merged from https://github.com/openssl/openssl/pull/25087)
The quic-srtm fuzzer uses a loop in which an integer command is
extracted from the fuzzer buffer input to determine the action to take,
switching on the values between 0 and 3, and ignoring all other
commands. Howver in the failing fuzzer test case here:
https://oss-fuzz.com/testcase-detail/5618331942977536
The buffer provided shows a large number of 0 values (indicating an SRTM
add command), and almost no 1, 2, or 3 values. As such, the fuzzer only
truly exercises the srtm add path, which has the side effect of growing
the SRTM hash table unboundedly, leading to a timeout when 10 entries
need to be iterated over when the hashtable doall command is executed.
Fix this by ensuring that the command is always valid, and reasonably
distributed among all the operations with some modulo math.
Introducing this change bounds the hash table size in the reproducer
test case to less than half of the initially observed size, and avoids
the timeout.
Fixesopenssl/project#679
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24827)
we extract several values (uint16_t and uint64_t from the fuzzer buff
passed in, but they weren't aligned on 2 and 8 byte boundaries. Adjust
the fuzzer to memcpy data to the target variables to avoid unalignment
issues
Fixes#24272
Reviewed-by: Paul Dale <ppzgs1@gmail.com>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
(Merged from https://github.com/openssl/openssl/pull/24276)
openssl-machine
Neil Horman
Burkov Egor
Andrew Dinh
Matt Caswell
Frederik Wedel-Heinen
Viktor Dukhovni
Jonathan M. Wilbur
Tomas Mraz
Mathis Marion
Dimitri Papadopoulos
Randall S. Becker
Max Ammann
Damian Hobson-Garcia
Richard Levitte
Job Snijders
Hugo Landau
Dr. David von Oheimb