Add support for hybrid key exchange protocol in Quarkus using openssl > 3.5#53076
Draft
anavarr wants to merge 1 commit intoquarkusio:mainfrom
Draft
Add support for hybrid key exchange protocol in Quarkus using openssl > 3.5#53076anavarr wants to merge 1 commit intoquarkusio:mainfrom
anavarr wants to merge 1 commit intoquarkusio:mainfrom
Conversation
The rise of quantum computers threatens traditional asymmetric key exchange protocol due to their ability to break private keys. Post-quantum cryptography must use problems that quantum computers can't solve as quickly. Module-lattice-based problems have been found to resist quantum computers. ML-KEM, for module-lattice-based key encapsulation mechanism, is an instance of a key exchange protocol resistant to quantum computers. Due to its relative short existence, it has been recommended to use it alongside traditional Diffie-Hellman with elliptic curve. Thus, the new hybrid key exchange protocol x25519mlkem768 uses both Diffie-Hellman with elliptic curve 25519 and ML-KEM. Its has been integrated in OpenSsl starting with version 3.5. Changes: This features relies on the netty-tcnative-openssl-dynamic bound to version 3.6 of openssl at runtime (provided by smallrye-openssl), and netty-tcnative-classes at build-time. Changes have been brought to Vert.x, we simply provide an API to setup the SSLEngine used in the underlying Vert.x server and/or client. In `application.properties`, user can set `quarkus.tls.my-config.hybrid=true` to leverage the new hybrid key exchange provided by OpenSSL > 3.5.
quarkus-bot
Bot
added
the
area/dependencies
Contributor
Author
|
the support was added in vertx 4.5.27, I'll mark the PR as ready for review when 4.5.27 is released. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The rise of quantum computers threatens traditional asymmetric key exchange protocol due to their ability to break private keys. Post-quantum cryptography must use problems that quantum computers can't solve as quickly. Module-lattice-based problems have been found to resist quantum computers. ML-KEM, for module-lattice-based key encapsulation mechanism, is an instance of a key exchange protocol resistant to quantum computers. Due to its relative short existence, it has been recommended to use it alongside traditional Diffie-Hellman with elliptic curve. Thus, the new hybrid key exchange protocol x25519mlkem768 uses both Diffie-Hellman with elliptic curve 25519 and ML-KEM. Its has been integrated in OpenSsl starting with version 3.5.
Changes:
This features relies on the netty-tcnative-openssl-dynamic bound to version 3.6 of openssl at runtime, and netty-tcnative-classes at build-time. Changes have been brought to Vert.x (see PR, we simply provide an API to setup the SSLEngine used in the underlying Vert.x server and/or client.
In
application.properties, user can setquarkus.tls.my-config.hybrid=trueto leverage the new hybrid key exchange provided by OpenSSL > 3.5.