Refactor CMAC init to common function, add wc_AesNew_Id/Label API, do same for RSA new
functions, and add test init helpers for id[] support along with some test disable options
Split make_check into two jobs to reduce CI time:
- make_check: 37 configs that interact with platform-specific features
(sys-ca-certs, Apple Security.framework, OpenSSL compat, networking)
continue to run on both Ubuntu and macOS.
- make_check_linux: 17 configs testing pure crypto algorithms,
preprocessor guards, or features with no macOS-specific code paths
now run on Linux only.
Also change make_user_settings_testwolfcrypt to Linux-only since
testwolfcrypt runs pure crypto tests with no platform-specific features.
Saves ~33 CI jobs with no loss of test coverage.
* implement legacy compatibility in settings.h and configure.ac (adds --enable-blake2b while retaining --enable-blake2);
* fix incorrect Blake2 gates in wolfcrypt/src/hash.c wc_HashGetDigestSize() and wc_HashGetBlockSize();
* in wolfcrypt/test/test.c hash_test(), backfill missing Blake2 test coverage and separate blake2b from blake2s in typesHashBad[];
* in tests/api/test_hash.c, separate blake2b from blake2s in notCompiledHash[], sizeSupportedHash[], and sizeNotCompiledHash[].
Reinitialize pointer fields in WOLFSSL_SESSION after raw XMEMCPY or
XFREAD in wolfSSL_memrestore_session_cache and
wolfSSL_restore_session_cache. After restore, ticket is reset to
staticTicket, ticketLenAlloc to 0, and peer to NULL.
Replace single last-byte padding check with full PKCS#5/PKCS#7
validation: verify padLen is non-zero and within block size.
Both wc_PKCS7_DecodeEnvelopedData and wc_PKCS7_DecodeEncryptedData
paths are fixed.
Add check before word32 addition in dilithium_hash256() that
could wrap to zero, bypassing the size check.
Also reject absurdly large msgLen (> UINT32_MAX/2) in
wc_dilithium_verify_ctx_msg.
Save key->heap before calling wc_*_free(), which zeros the entire key
structure via ForceZero. The saved heap pointer is then passed to XFREE
instead of the now-zeroed key->heap.
Validate that the received key share data length (keLen) is at least
as large as the expected ciphertext size (ctSz) before passing it to
wc_KyberKey_Decapsulate. A malicious TLS 1.3 server could send a
short ML-KEM key share.
night1rider
David Garske
Tobias Frauenschläger
JacobBarthelmeh
Sean Parkinson
Eric Blankenhorn
Juliusz Sosinowicz
Ruby Martin
Daniel Pouzzner
sebastian-carpenter
Paul Adelsbach
Anthony Hu