* 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
* DTLS 1.3 cookie and CH frag handling
* static memory handling
* Fix memory leak in TLS server PQC handling in case of ECH
* Make sure hybrids are actually tested in testsuite
CRL APIs not usable when NO_ASN_TIME defined.
WOLFSSL_TLS13 needs to be defined with HAVE_ECH.
When session ticket encrypted with CBC, must be a multiple of block
size.
Fix test define protection.
Fix ML-DSA protection of reduction functions.
Need !NO_RSA with WC_RSA_PSS.
Connection ID is not a DTLS 1.3 only extension.
wc_lms_treehash_init() writes leaf node hashes into the leaf cache
using an absolute index (i * hash_len), but the cache is only
max_cb entries starting from leaf->idx. When leaf->idx > 0 (which
occurs when wc_LmsKey_Reload is called after signing more than
max_cb times), the write goes past the end of the cache buffer.
Fix by using the relative offset (i - leaf->idx) * hash_len instead.
Added unit tests (test_lms.c):
- test_wc_LmsKey_sign_verify: basic sign/verify sanity check
- test_wc_LmsKey_reload_cache: (TDD) reproduces the overflow by
signing 33 times then reloading the key
OCSP Responder Core API:
- Add new public API for creating and managing an OCSP responder
- Add public wrappers for internal OCSP request/response functions
- OcspRespCheck: fix check when authorized responder is loaded into CM
Header Cleanup:
- Remove circular dependency when including `#include <wolfssl/wolfcrypt/asn.h>` from wolfssl/wolfcrypt/ecc.h and wolfssl/wolfcrypt/rsa.h
OCSP Responder Example (examples/ocsp_responder/):
- Add a command-line OCSP responder for interoperability testing with OpenSSL's `openssl ocsp` client
Test Scripts (scripts/):
- ocsp-responder-openssl-interop.test: Tests wolfSSL OCSP responder with `openssl ocsp` client
- ocsp-stapling-with-wolfssl-responder.test: Tests wolfSSL OCSP responder when doing OCSP stapling
Certificate Infrastructure (certs/ocsp/):
- Add DER-format certificates and keys for OCSP testing
- Update renewcerts.sh to generate DER versions
Known Limitations (documented in src/ocsp.c header comment):
- Single request/response per OCSP exchange only
- Key-hash responder ID only (no name-based responder ID)
- No singleExtensions support
- Add a GitHub Actions workflow to automate testing of Python integration
- Implement Blake2b and Blake2s hash functions into the EVP API.
- Improve OpenSSL compatibility by standardizing ASN.1 encoding for
serial numbers and registered IDs, streamlining cipher stack management, and optimizing stack node copying.
- Enforce maximum fragment size during data transmission to ensure proper TLS/DTLS record fragmentation.
When a server uses a HRR to negotiate the key exchange group to use, the
selected group is advertised in the HRR key share extension.
Furthermore, this group is also stored in the Cookie that is sent to the
client. When the server receives the second CH, the group used in the
key share extension MUST be the one of the HRR.
For stateless DTLS servers, the handling of this check had a bug. The
key share group of the HRR is stored in the ssl->hrr_keyshare_group
variable and is checked against the received key share of the second CH.
However, in the stateless server case, another CH message may be
received inbetween the two CH message of the desired client, potentially
overwriting the ssl->hrr_keyshare_group variable. This then causes
handshake failures when the ssl->hrr_keyshare_group variable contains
another group than the second CH message of the desired client.
To fix this, the following changes are conducted:
1. Disable the ssl->hrr_keyshare_group check for stateless DTLS 1.3
servers. As long as the server is stateless, CHs from multiple
clients may be received that individually cause HRRs with different
groups. For each of these clients, the HRR group is properly stored
in the cookie.
2. When a valid cookie is received from the client, the server becomes
stateful. In this case, we now parse the cookie for a stored HRR
group in the RestartHandshakeHashWithCookie() method. If present,
we restore the ssl->hrr_keyshare_group variable to this group to
ensure the error checks succeed.
3. Move the check of ssl->hrr_keyshare_group of the the KeyShare
extension parsing logic into the general TLS1.3 ClientHello parsing
after extension handling. This ensures that the order of the cookie
and key share extensions does not matter.
A new test is added to check for this behavior.
David Garske
JacobBarthelmeh
Eric Blankenhorn
Tobias Frauenschläger
Juliusz Sosinowicz
Chris Conlon
sebastian-carpenter
Sean Parkinson
Anthony Hu
Daniel Pouzzner
Hideki Miyazaki
Paul Adelsbach