* in pbkdf2_test(), pwdbased_test(), and pkcs12_test(), add missing FIPS v7+
gates around stanzas that use wc_PBKDF_max_iterations_set() and
wc_PBKDF_max_iterations_get() or depend on erroring for excessive PBKDF
iterations (fixes#10050);
* in ecc_test_buffers(), omit new corrupt HMAC tag test on FIPS <v6 (fixes
8f2a3f9563).
tests/api/test_dtls.c: add FIPS v7+ gate to test_dtls13_frag_ch2_with_ch1_rtx().
wolfssl/wolfcrypt/memory.h: #include "../../linuxkm/linuxkm_memory.h" rather than "linuxkm/linuxkm_memory.h", following pattern in wc_port.h.
* Enable ML-KEM by default in build systems (autoconf and CMake)
* Only allow three to-be-standardized hybrid PQ/T combinations by
default
* Use X25519MLKEM768 as the default KeyShare in the ClientHello (if user
does not override that). When Curve25519 is disabled, then either
WOLFSSL_SECP384R1MLKEM1024 or WOLFSSL_SECP256R1MLKEM768 is used as
default depending on the ECC configuration
* Disable standalone ML-KEM in supported groups by default (enable with
--enable-tls-mlkem-standalone)
* Disable extra OQS-based hybrid PQ/T curves by default and gate
behind --enable-experimental (enable with --enable-extra-pqc-hybrids)
* Reorder the SupportedGroups extension to reflect the preferences
* Reorder the preferredGroup array to also reflect the same preferences
* Add async support for ML-KEM hybrids
Order of preference, based on algorithms compiled in, to use with HMAC
for TLS 1.3 cookie:
1. SHA-256
2. SHA-384
3. SHA-512
4. SM3
Make code compile and unittest pass when SHA-256 not compiled in.
Certificates used for testing require SHA-256 so handshake testing
fails.
Otherwise the connection can stall due the indefinite delay of an explicit ACK,
for exapmle:
-> client sends the last Finished message
<- server sends the ACK, but the ACK is lost
-> client rentrasmit the Finished message
- server delay sending of the ACK until a fast timeout
-> client rentrasmit the Finished message quicker than the server timeout
- server resets the timeout, delaying sending the ACK
-> client rentrasmit the Finished...
Dlts13NewEpoch saves the keys currently derived in the ssl object.
Moving Dtls13NewEpoch inside DeriveTls13Keys avoid the risk of using the wrong
keys when creating a new Epoch.
This fixes at least he following scenario:
- Client has encryption epoch != 2 in the handshake (eg. due to rtx)
- Client derives traffic0 keys after receiving server Finished message
- Client set encryption epoch to 2 again to send the Finished message, this
override the traffic key computed
- Client creates the new epoch with the wrong key
Daniel Pouzzner
rizlik
Reda Chouk
Juliusz Sosinowicz
Tobias Frauenschläger
JacobBarthelmeh
David Garske
Sean Parkinson