Add support for hybrid key exchange protocol x25519mlkem768. #5829
Conversation
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
…g TLS sessions quantum safe. This features relies on the netty-tcnative-openssl-dynamic bound to version 3.6 of openssl. - Add boolean useHybrid field to io.vertx.core.net.SSLOptions and create getters/setters in io.vertx.core.net.SSLOptions as well as every implementation of io.vertx.core.net.TCPSSLOptions. - If this value is set to true (default false), the ssl handler will be set to use x25519mlkem768 instead of x25519. - If key exchange protocol is set to x25519mlkem768 but JdkSsl is used instead of OpenSsl, or the version of openssl used at runtime does not suppot x25519mlkem768, the user is informed that hybrid key exchange is impossible channel is closed
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.
Motivation:
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.