Follow up to PR #10450 with some minor fixes:
* FIPS 205 numbering: slh_sign is §10.2.1 Alg 22; slh_verify is Alg 24;
hash_slh_verify is Alg 25 (impl comments and doxygen).
* Widen wc_SlhDsaKey_SignHashWithRandom's addRnd to const byte* to
match wc_SlhDsaKey_SignWithRandom.
* Make the SLHDSA_PHMSG_MAX_LEN invariant explicit with a named
SLHDSA_LARGEST_APPROVED_PHM_LEN constant and a wc_static_assert.
* SHAKE128/SHAKE256 round-trip and length-rejection coverage for both
SignHash and VerifyHash.
* Doxygen: briefs for the five DER encode/decode APIs; accurate
decoder failure-rollback wording; tighter return-code lists for
Verify and VerifyMsg.
* ChangeLog: silent-failure caveat for raw messages whose length
happens to equal the digest size of the chosen hashType.
wc_SlhDsaKey_{Sign,Verify}Hash* previously accepted the raw message and
performed the pre-hash internally. They now require the caller to hash the
message first and pass the resulting digest -- the functions no longer call
wc_*Hash() themselves and feed the supplied digest directly into the M'
construction. Parameters are renamed from msg/msgSz to hash/hashSz to reflect
this, and hashSz is validated against wc_HashGetDigestSize(hashType) per
FIPS 205 Section 10.2.2 (32 for SHAKE128, 64 for SHAKE256), returning
BAD_LENGTH_E on mismatch.
This matches ML-DSA's wc_dilithium_{sign,verify}_ctx_hash, NIST ACVP
signatureInterface=external / preHash=preHash vectors, and other libraries
(OpenSSL HASH-ML-DSA, leancrypto, mldsa-native). It also enables distributed
signers and HSM-style flows where the digest is computed separately from the
signing operation.
Migration: callers must now hash the message before invoking these APIs;
passing the raw message will either fail length validation or produce
signatures over the wrong input. The M'-supplied wc_SlhDsaKey_SignMsg* /
VerifyMsg family (FIPS 205 internal interface, Algorithms 19/20) is
unchanged but gains stricter input validation and doxygen coverage.
When WOLF_CRYPTO_CB_AES_SETKEY is enabled and a CryptoCB callback
imports the AES key into a Secure Element (aes->devCtx != NULL), the
TLS-layer copy in keys->{client,server}_write_key has no further
consumer: the software key schedule is not populated on offload.
ForceZero it in SetKeysSide() per provisioned side.
The static IVs (keys->{client,server}_write_IV and
keys->aead_{enc,dec}_imp_IV) are left intact because BuildTls13Nonce()
reads aead_{enc,dec}_imp_IV on every record (RFC 8446 Section 5.3).
Scope: TLS 1.3, non-DTLS, non-QUIC. DTLS 1.3 needs the write keys
in Dtls13EpochCopyKeys; TLS 1.2 needs them for rehandshake; QUIC is
untouched pending audit.
Add two memio tests (test_wc_CryptoCb_Tls13_Key_{Zero_After_Offload,
No_Zero_Without_Offload}) that pin AES-GCM and check key / IV state
after the handshake and a KeyUpdate round.
Signed-off-by: Sameeh Jubran <sameeh@wolfssl.com>
Tobias Frauenschläger
Sameeh Jubran
JacobBarthelmeh
Eric Blankenhorn
Joshua Okeleke
Daniel Pouzzner
Lealem Amedie
Chris Conlon
Dimitri Papadopoulos
John Safranek
Anthony Hu