The WOLF_CRYPTO_CB_FREE path in wc_MlKemKey_Free, wc_dilithium_free,
and wc_ecc_free returned early when the crypto callback succeeded,
skipping local cleanup: ForceZero on private key material, PRF/hash
object frees (ML-KEM), SHAKE free and cached vector frees (ML-DSA),
and mp_forcezero on the private scalar and all hardware port frees
(ECC).
Any non-PKCS#11 callback returning 0 would silently leave key material
in memory. The PKCS#11 backend worked around this by returning
CRYPTOCB_UNAVAILABLE on success to force the fallthrough — a fragile
contract that is not part of the documented callback interface.
Fix by always continuing to software cleanup after invoking the
callback.
Remove the CRYPTOCB_UNAVAILABLE workaround from the three PKCS#11 free
dispatchers (ECC, ML-DSA, ML-KEM); they now return the real result of
C_DestroyObject.
Add PKCS#11 integration for ML-KEM with key generation,
encapsulation and decapsulation support through the crypto
callback path.
Includes ML-KEM PKCS#11 constants/types, key store handling,
token object lifecycle management, and ML-KEM key init helpers
for private-key ID/label workflows.
Align implementation details with current upstream conventions
and review feedback:
- internal wolfCrypt ML-KEM path only for PKCS#11
- inline ML-KEM key-type/flag checks in PKCS#11 code
- proper key template formatting and enum placement
- ensure TLS ML-KEM object storage behavior is compatible with
PKCS#11 ephemeral-key decapsulation flow
* 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[].
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.
OCSPBASICRESPASN_IDX_SIGNATURE_PARAMS is only defined when WC_RSA_PSS
is enabled but was used unconditionally in EncodeBasicOcspResponse,
causing a build error when WC_RSA_PSS is not defined.
When an EC_KEY is created via EC_KEY_new + EC_KEY_set_group +
EC_KEY_set_private_key (no public point set), SetECKeyInternal
incorrectly marks the internal ecc_key as ECC_PRIVATEKEY (instead of
ECC_PRIVATEKEY_ONLY) because pub_key is always non-NULL — EC_KEY_new
always allocates it as an empty, zero-initialised EC_POINT.
ECC_populate_EVP_PKEY only calls wc_ecc_make_pub for ECC_PRIVATEKEY_ONLY
keys, so the zero public-key point was serialised into the DER stored in
pkey->pkey.ptr. After commit 929dd9913 made wc_ecc_import_x963_ex always
pass untrusted=1, the re-decode inside wolfSSL_EVP_PKEY2PKCS8 →
wolfSSL_d2i_PrivateKey_EVP correctly rejected that zero point with an
on-curve failure, causing EVP_PKEY2PKCS8 to return NULL.
Fix: in ECC_populate_EVP_PKEY, also call wc_ecc_make_pub when the key
type is ECC_PRIVATEKEY but pubkey.x is zero (meaning the public key was
never actually populated). This reconstructs the public key from the
private scalar so that the encoded DER contains a valid on-curve point.
wc_ecc_import_x963_ex2 only checked whether an imported public point
lies on the intended curve when both USE_ECC_B_PARAM was compiled in
and the caller passed untrusted=1. In a default ./configure build,
USE_ECC_B_PARAM is not defined, so the check was compiled out entirely.
Additionally, the legacy wrapper wc_ecc_import_x963_ex unconditionally
passed untrusted=0, meaning ECIES (wc_ecc_decrypt), PKCS#7 KARI, and
the EVP ECDH layer never triggered the check even when the macro was
present. In the OpenSSL compatibility layer, wolfSSL_ECPoint_d2i
guarded its on-curve check behind !wolfSSL_BN_is_one(point->Z), but
wc_ecc_import_point_der_ex always sets Z=1 for uncompressed points,
making the check dead code.
An attacker who can supply an EC public key (e.g. via an ECIES
ciphertext, PKCS#7 enveloped-data, EVP_PKEY_derive, or
EC_POINT_oct2point + ECDH_compute_key) can choose a point on a twist
of the target curve with a smooth-order subgroup. Each ECDH query
leaks the victim's static private scalar modulo a small prime; CRT
reconstruction across enough queries recovers the full key
(Biehl-Meyer-Müller invalid-curve attack). Static-key ECIES and PKCS#7
KARI are directly affected; TLS is affected in default builds because
the USE_ECC_B_PARAM gate defeated the untrusted=1 flag that the
handshake does pass.
Four changes close the attack:
1. Remove the USE_ECC_B_PARAM gate completely in the code base so that
wc_ecc_point_is_on_curve() is compiled in all builds, not only
those with HAVE_COMP_KEY or OPENSSL_EXTRA (only set for legacy FIPS
builds in settings.h).
2. wc_ecc_import_x963_ex: pass untrusted=1 to wc_ecc_import_x963_ex2
so that ECIES, PKCS#7 KARI, and EVP callers that go through the
four-argument wrapper always validate the imported point.
3. wc_ecc_import_x963_ex2: use the lightweight sp_ecc_is_point_NNN
helpers (curve-equation check only) instead of sp_ecc_check_key_NNN
(which additionally performs a full point*order scalar multiply).
For prime-order curves (P-256, P-384, P-521, SM2) the on-curve
equation check y^2 = x^3 + ax + b is sufficient to defeat
invalid-curve attacks — every non-identity point on a prime-order
curve has the full group order, so the expensive order-multiply
check is unnecessary. This avoids the ~50% ECDH performance
regression caused by the redundant scalar multiplication.
4. wolfSSL_ECPoint_d2i (pk_ec.c): add unconditional on-curve
validation via wolfSSL_EC_POINT_is_on_curve after import. The
existing check was gated on !wolfSSL_BN_is_one(point->Z) and
therefore dead code for all uncompressed-point imports. This closes
the OpenSSL compat layer attack path (EC_POINT_oct2point followed
by ECDH_compute_key).
Non-SP curves fall back to wc_ecc_point_is_on_curve which performs the
same equation check using mp_int arithmetic.
Reported by: Nicholas Carlini (Anthropic) & Thai Duong (Calif.io)
* wc_rng_bank_default_set()
* wc_rng_bank_default_checkout()
* wc_rng_bank_default_checkin()
* wc_rng_bank_default_clear()
* Added additional argument error checking to existing APIs, with a new
rng_inst_matches_bank() helper function.
* Implemented feature gates WC_RNG_BANK_DEFAULT_SUPPORT and
WC_RNG_BANK_NO_DEFAULT_SUPPORT. When WC_RNG_BANK_DEFAULT_SUPPORT, the new
APIs are available, and a NULL bank passed to APIs implicitly refers to the
default bank.
wolfcrypt/test/test.c: in random_bank_test() add comprehensive smoke test coverage of new APIs and argument checking.
wolfssl/wolfcrypt/wc_port.h and wolfcrypt/src/wc_port.c:
* Add wolfSSL_RefInc2(), wolfSSL_RefDec2(), wolfSSL_RefWithMutexInc2(), and
wolfSSL_RefWithMutexDec2(), returning the atomically determined new count in
the second arg;
* Fix type of second arg in the fallback definition of
wolfSSL_Atomic_Ptr_CompareExchange().
linuxkm/lkcapi_sha_glue.c:
Refactor the _REGISTER_HASH_DRBG / _REGISTER_HASH_DRBG_DEFAULT facility around
the new wc_rng_bank_default facility, eliminating post-init use of
kernel-native crypto_default_rng, crypto_get_default_rng(), and
crypto_put_default_rng(), and eliminating all use on kernel 7.1+ (where these
will become unexported kernel-native statics). With the refactor, the
LINUXKM_DRBG_GET_RANDOM_BYTES facility uses only direct native wolfCrypt
objects and calls to fulfill requests.
wolfssl/wolfcrypt/error-crypt.h, wolfcrypt/src/error.c, wolfcrypt/test/test.c, tests/api.c: add WC_SUCCESS = 0 "wolfCrypt generic success".
* add WC_FIPS_186_4, WC_FIPS_186_4_PLUS, WC_FIPS_186_5, and WC_FIPS_186_5_PLUS feature macros.
* add support for WC_HASH_CUSTOM_MIN_DIGEST_SIZE, WC_HASH_CUSTOM_MAX_DIGEST_SIZE, and
WC_HASH_CUSTOM_MAX_BLOCK_SIZE, for use with custom digest algorithms.
* add SigOidMatchesKeyOid() helper function and WC_MIN_DIGEST_SIZE macro.
* add additional size and OID agreement checks for sig gen and verify ops.
* update ecc_test_vector() with FIPS 186-5 vectors.
Co-authored-by: Tobias Frauenschläger <tobias@wolfssl.com>
When an EC_KEY is created via EC_KEY_new + EC_KEY_set_group +
EC_KEY_set_private_key (no public point set), SetECKeyInternal
incorrectly marks the internal ecc_key as ECC_PRIVATEKEY (instead of
ECC_PRIVATEKEY_ONLY) because pub_key is always non-NULL — EC_KEY_new
always allocates it as an empty, zero-initialised EC_POINT.
ECC_populate_EVP_PKEY only calls wc_ecc_make_pub for ECC_PRIVATEKEY_ONLY
keys, so the zero public-key point was serialised into the DER stored in
pkey->pkey.ptr. After commit 929dd9913 made wc_ecc_import_x963_ex always
pass untrusted=1, the re-decode inside wolfSSL_EVP_PKEY2PKCS8 →
wolfSSL_d2i_PrivateKey_EVP correctly rejected that zero point with an
on-curve failure, causing EVP_PKEY2PKCS8 to return NULL.
Fix: in ECC_populate_EVP_PKEY, also call wc_ecc_make_pub when the key
type is ECC_PRIVATEKEY but pubkey.x is zero (meaning the public key was
never actually populated). This reconstructs the public key from the
private scalar so that the encoded DER contains a valid on-curve point.
wc_PKCS7_DecodeAuthEnvelopedData() accepted an attacker-controlled GCM tag
length from the mac OCTET STRING and did not validate it against the
parsed aes-ICVlen parameter. In parallel, wc_AesGcmDecrypt() accepted
very short tags on decrypt while encrypt enforced WOLFSSL_MIN_AUTH_TAG_SZ.
This made short-tag verification reachable through CMS AuthEnvelopedData
and weakened integrity checks by allowing tag truncation.
Fixes:
- validate parsed macSz range in AuthEnvelopedData decode
- require authTagSz to match parsed macSz
- reject undersized GCM tags in PKCS7 decode
- enforce WOLFSSL_MIN_AUTH_TAG_SZ in wc_AesGcmDecrypt() and
wc_AesGcmDecryptFinal()
Also add a regression test in pkcs7authenveloped vectors that truncates
the final MAC OCTET STRING length from 16 to 1 and verifies decode fails.
Reported by: Nicholas Carlini (Anthropic) & Thai Duong (Calif.io)
EVP_DecryptFinal_ex() called wc_ChaCha20Poly1305_Final() which only
computes the Poly1305 tag, writing it into ctx->authTag and
overwriting the expected tag stored there by EVP_CTRL_AEAD_SET_TAG.
No comparison was ever performed, so any forged tag was accepted.
Fix: save the expected tag before calling Final(), then verify with
wc_ChaCha20Poly1305_CheckTag() on the decrypt path, mirroring the
existing AES-GCM branch. Add a regression test that asserts
EVP_DecryptFinal_ex() rejects an all-zero forged tag.
Reported-by: Nicholas Carlini (Anthropic) & Bronson Yen (Calif.io)
wc_VerifyEccsiHash did not validate that r and s lie in [1, q-1]
after decoding them from the signature buffer. With s=0 the scalar
multiplication [s](...) returns the point at infinity (J_x=0); with
r=0 the final mp_cmp(0,0)==MP_EQ check then accepts the forged
signature unconditionally against any message and any identity.
Add [1, q-1] range checks for r (in wc_VerifyEccsiHash, after params
are loaded) and for s (in eccsi_calc_j, after eccsi_decode_sig_s),
mirroring the checks already present in wc_ecc_check_r_s_range.
Add a defense-in-depth point-at-infinity guard on J before the final
comparison.
Reported-by: Nicholas Carlini (Anthropic) & Bronson Yen (Calif.io)
The guard `if (cmac->totalSz != 0)` was used to skip XOR-chaining on
the first block (where digest is all-zeros and the XOR is a no-op).
However, totalSz is word32 and wraps to zero after 2^28 block flushes
(4 GiB), causing the guard to erroneously fire again and discard the
live CBC-MAC chain state. Any two messages sharing a common suffix
beyond the 4 GiB mark then produce identical CMAC tags, enabling a
zero-work prefix-substitution forgery. The fix removes the guard,
making the XOR unconditional; the no-op property on the first block is
preserved because digest is zero-initialized by wc_InitCmac_ex.
Identified by: Nicholas Carlini (Anthropic) & Thai Duong (Calif.io)
David Garske
Tobias Frauenschläger
JacobBarthelmeh
Sean Parkinson
Juliusz Sosinowicz
Daniel Pouzzner
Paul Adelsbach
Anthony Hu
philljj