-
Notifications
You must be signed in to change notification settings - Fork 845
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add more PQC hybrid key exchange algorithms #7821
Add more PQC hybrid key exchange algorithms #7821
Conversation
Can one of the admins verify this patch? |
Okay to test. Contributor agreement on file. @anhu please review. Thanks |
Seems to be consistently failing with:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please be sure to test against --enable-kyber
ca3082c
to
cab79bc
Compare
Updated the PR with a fix for the failing tests.
The tests now properly work with Furthermore, I updated the unit tests to also test the new changes. The only thing I had to test manually are the new hybrid curves with DTLS (when also enabled with |
Hi @Frauschi we had some issues with our GitHub CI actions. If you rebase this to latest master it should resolve the errors you are seeing. Thank you |
cab79bc
to
817d95e
Compare
Rebased to current master. Thanks for the hint. FYI, I'm on vacation for the next two weeks, so any upcoming work on this will probably be delayed until afterward. |
817d95e
to
418b80e
Compare
Rebased to current master (since #7807 has been merged). I also think that the one NGINX test that has been failing wasn't related to this PR's changes? Can someone retest this please? |
retest this please. |
This says the branch has conflicts that must be resolved. Could you rebase on top of wolfssl/master please? |
418b80e
to
6d0774b
Compare
Rebased to current master. I also updated the PR to reflect the latest Code Point changes in OQS and also incorporated the new Code Points currently set in draft-kwiatkowski-tls-ecdhe-mlkem. The only thing that is not done yet is the proposed swap of classic and PQC key material within draft-kwiatkowski-tls-ecdhe-mlkem in the key share in case of X25519 hybrids. This is done to always have a FIPS approved algorithms first in case of hybrids (and X25519 is not FIPS approved). See here. This swap still has to be implemented. However, that will require more thorough code changes. I think I can tackle that around next week. You can decide if this should also go into this PR, or if that should go in a separate one. |
6d0774b
to
eb58d46
Compare
I updated the PR with two new commits to implement the reversed order of X25519/X448 based hybrids, following draft-kwiatkowski-tls-ecdhe-mlkem now. I tested compatibility with both Firefox and Google Chrome nightly, as both have support for For testing the Round 3 compatibility, I used liboqs as the WolfSSL implementation is not working properly currently (see #8023). |
eb58d46
to
6d715a2
Compare
With the fixes in #8027 applied, we now also have compatibility with current versions of Chrome and Firefox when compiled with the WolfSSL Kyber implementation and with |
6d715a2
to
907077d
Compare
907077d
to
8858ac7
Compare
I updated the PR, replacing the three commits with two new ones. The first is a concatenation of the old three ones with further additions. The second one is a proposed fix for #8024. The first commit adds the new X25519 / X448 hybrids, both for the draft and final versions of ML-KEM (based on the recent addition in #8143). This enables PQC compatibility with all current browsers. I also updated some of the code points to reflect the latest drafts of draft-connolly-tls-mlkem-key-agreement and draft-kwiatkowski-tls-ecdhe-mlkem. The proposed fix in the second commit is a simple but pragmatic solution for #8024. If you don't see that as a proper solution or if you prefer to handle that in a separate PR, I can drop the commit. Tagging @SparkiDev and @ColtonWilley in addition to @anhu to also take a look at the changes. |
Hi @Frauschi , |
The two new macros are from liboqs to determine if the final ML-KEM version is available or only the original Kyber version. Based on the hint from @anhu, I see three possibilities now:
|
Hi @Frauschi , I think we already have macros for this. See |
502b897
to
2b4d2fd
Compare
I replaced the two liboqs macros with the WolfSSL ones ( Removal of liboqs support should be independent of this PR as all liboqs related changes are wrapped in |
BTW, the TLSX changes in #8467 are partly equivalent to the latest changes I did in this PR to keep the generated KyberKey object during the handshake. |
@Frauschi the other PR #8467 has been merged. Looks like your PR has some conflicts now. Would you mind resolving those? Thank you again for all your amazing work! |
2b4d2fd
to
d501cf9
Compare
Rebased and resolved the conflicts after #8467. Should be good to go now (hopefully). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice work! Just a simple cast issue with g++. Otherwise this looks complete and high quality.
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 <[email protected]>
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 <[email protected]>
d501cf9
to
c899f79
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @Frauschi . You are amazing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some really great work @Frauschi !! Thank you so much!
Retest this please: "Found unhandled org.jenkinsci.plugins.workflow.support.steps.AgentOfflineException exception" |
Hi,
This PR adds support for all remaining hybrid PQC + ECC hybrid key exchange groups to match OQS. Next to two new combinations with SECP curves, this mainly also adds support for combinations with X25519 and X448.
This also enables compatibility with the PQC key exchange support in Chromium browsers and Mozilla Firefox (hybrid Kyber768 and X25519; when
WOLFSSL_ML_KEM
is not defined).In the process of extending support, some code and logic cleanup happened. Furthermore, two memory leaks within the hybrid code path have been fixed.
Looking forward to your feedback.