* 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