In case no user group ranking is set, all groups are now ranked equally
instead of the order in the `preferredGroup` array. This is the
behavior already indicated in the comment header of the function.
This change is necessary for applications that do not set their own
group ranking (via `wolfSSL_CTX_set_groups()` for example). When such an
application creates a TLS server and receives a ClientHello message with
multiple key shares, now the first key share is selected instead of the
one with the lowest index in the `preferredGroup` array.
Recent browsers with PQC support place two key shares in their
ClientHello message: a hybrid PQC + X25519 one and at least one
classic-only one. The hybrid one is the first one, indicating a
preference. Without this change, however, always the classic-only key
share has been selected, as these algorithms have a lower index in the
`preferredGroup` array compared to the PQC hybrids.
Tested using a patched version of NGINX.
This change also results in a different selection of a key share group
in case of a HelloRetryRequest message. For the tests, where static
ephemeral keys are used (`WOLFSSL_STATIC_EPHEMERAL`), an additional
check is necessary to make sure the correct key is used for the ECDH
calculation.
Signed-off-by: Tobias Frauenschläger <tobias.frauenschlaeger@oth-regensburg.de>
Add support for X25519 and X448 based hybrid PQC + ECC key exchange
groups. Furthermore, two new combinations with SECP curves are added to
match OQS combinations.
This also incorporates the changed order of X25519 and X448 based
combinations to place the PQC material before the ECDH material. This is
motivated by the necessity to always have material of a FIPS approved
algorithm first.
Also, codepoints are updated to reflect the latest draft standards for
pure ML-KEM and some of the hybrids. With these changes and based on the
recent additions to both enable ML-KEM final and draft versions
simultaneously, a WolfSSL TLS server is now compatible with all recent
browsers that support either the draft version of ML-KEM (Chromium based
browsers and Firefox < version 132; only when the draft version is
enabled in the build) or the final version already (Firefox > version 132).
In the process of extending support, some code and logic cleanup
happened. Furthermore, some memory leaks within the hybrid code path have
been fixed.
Signed-off-by: Tobias Frauenschläger <tobias.frauenschlaeger@oth-regensburg.de>
Threads::Threads is not defined, if support not found for some reason
if custom threads support is used then it happen always
of cause some tests relates to standard threads support then it fails during build, but build is started and only some tests fail
ML-KEM/Kyber:
MakeKey call generate random once only for all data.
Allow MakeKey/Encapsulate/Decapsulate to be compiled separately.
Pull out public key decoding common to public and private key decode.
Put references to FIPS 140-3 into code. Rename variables to match FIPS
140-3.
Fix InvNTT assembly code for x64 - more reductions.
Split out ML-KEM/Kyber tests from api.c.
TLSX:
Store the object instead of the private key when WOLFSSL_MLKEM_CACHE_A
is defined or WOLFSSL_TLSX_PQC_MLKEM_STORE_OBJ. Faster decapsulation
when A is cached and object stored.
To store private key as normal define
WOLFSSL_TLSX_PQC_MLKEM_STORE_PRIV_KEY.
misc.c: when Intel x64 build, assume able to read/write unaligned
- Added a new test case `resp_bad_embedded_cert` in
`create_ocsp_test_blobs.py` to test OCSP response with an unusable
internal cert that can be verified in Cert Manager.
- Updated `test_ocsp_response_parsing` in `ocsp.c` to include the new
test case.
- Ensured the new test case checks for proper handling of OCSP responses
with incorrect internal certificates.
