This update introduces the WOLFSSL_DILITHIUM_DYNAMIC_KEYS option, allowing
for dynamic memory allocation of public and private key buffers. This change
reduces memory usage by allocating buffers only when needed.
Add NULL and bounds validation to public API entry points that
were missing basic argument checks. Fixes span ALPN, session cache,
X509, SRP, PrivateKey ID/Label, and OBJ_obj2txt.
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
Introduce the WOLFSSL_MLKEM_DYNAMIC_KEYS option to allow dynamic allocation
of private and public key buffers in the MlKemKey struct. This change
enables right-sizing of buffers based on the actual ML-KEM level and eliminates
unnecessary memory usage for encapsulate-only operations.
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