Skip to content

Add support for hybrid key exchange protocol x25519mlkem768#6107

Open
anavarr wants to merge 5 commits into
eclipse-vertx:masterfrom
anavarr:master
Open

Add support for hybrid key exchange protocol x25519mlkem768#6107
anavarr wants to merge 5 commits into
eclipse-vertx:masterfrom
anavarr:master

Conversation

@anavarr
Copy link
Copy Markdown

@anavarr anavarr commented May 6, 2026

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.

  • 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, then SSL handshake fails

@anavarr
Copy link
Copy Markdown
Author

anavarr commented May 6, 2026

@vietj

@zekronium
Copy link
Copy Markdown
Contributor

We ported something similar ourselves by bumping tcnatuve, are the extra methods really needed instead of simply setting/adding the curve to sslconfig when creating netclient/httpclient

@vietj vietj added this to the 5.1.0 milestone May 11, 2026
Comment thread vertx-core/src/main/java/io/vertx/core/net/ServerSSLOptions.java Outdated
Comment thread vertx-core/src/main/java/io/vertx/core/net/SSLOptions.java Outdated
Comment thread vertx-core/src/main/java/io/vertx/core/net/SSLOptions.java Outdated
Comment thread vertx-core/src/test/java/io/vertx/it/HybridKeyExchangeTest.java Outdated
CompletableFuture<Boolean> cf1 = new CompletableFuture<>();
CompletableFuture<Boolean> cf2 = new CompletableFuture<>();

client.request(HttpMethod.GET, DEFAULT_HTTPS_PORT, DEFAULT_HTTPS_HOST, "/").onComplete(onSuccess(req -> {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

instead use request/response composition with await() on the future to avoid usage of CompletableFuture and make the test simpler

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you can look at how other tests are doing, e.g.:

    Buffer body = client.request(new RequestOptions(requestOptions).setMethod(PUT))
      .compose(req -> req
        .send(expected)
        .expecting(HttpResponseExpectation.SC_OK)
        .compose(HttpClientResponse::body))
      .await();

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants