Why enable post-quantum key exchange right now
Because traffic can be recorded today and decrypted later, once a sufficiently powerful quantum computer exists. This is called “store now, decrypt later”. Only a key exchange that resists quantum attacks protects against that scenario, and you can switch it on at the server today — for both TLS and SSH.
The threat is named directly in the OpenSSH 10.1 release notes: the warning about a non-post-quantum exchange was added because of the risk of “store now, decrypt later” attacks. Signatures and certificates are a separate topic and are not covered here.
What X25519MLKEM768 is and what RFC 10024 defines
X25519MLKEM768 is a hybrid key exchange for TLS 1.3: it combines classical X25519 with the post-quantum ML-KEM. It is described in RFC 10024 (Standards Track, August 2026). Both mechanisms protect the session at once.
An important detail: RFC 10024 defines three hybrids, not one — X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024. Each combines ML-KEM with an ECDHE exchange. Write the name exactly: the group is set by that name in the configuration. The old draft name X25519Kyber768Draft00 is obsolete and incompatible with the current one.
What TLS needs: versions and checks
TLS needs one thing: a web server built with OpenSSL 3.5.0 or newer. nginx has no minimum version of its own for post-quantum exchange — everything depends on the OpenSSL version it was built with. Browsers, judging by their own publications, offer the hybrid on their own, so only the server needs attention.
| Component | What is required | How to check |
|---|---|---|
| OpenSSL | version 3.5.0 or newer: it added ML-KEM and hybrid TLS groups, and offers X25519MLKEM768 and X25519 by default | openssl version |
| nginx | no minimum version of its own, what matters is the OpenSSL it was built with | nginx -V |
openssl version
nginx -V 2>&1 | grep -i "built with"The first command shows the system OpenSSL version, the second shows which version nginx was built with. If the version is below 3.5.0, post-quantum groups are unavailable and you need a different build. How to read the certificate itself is covered in the article on checking an SSL certificate.
How to enable post-quantum TLS in nginx
If nginx is built with OpenSSL 3.5.0 or newer, you usually need to change nothing: the ssl_ecdh_curve directive defaults to auto, meaning the OpenSSL list is used, and that list prefers hybrid groups. If you need an explicit list, it takes a single line.
A caveat: the conclusion about auto is an inference from the OpenSSL notes and the nginx documentation, which has no direct statement on it. Verify on your own build.
- Make sure nginx is built with OpenSSL 3.5.0 or newer.
- Keep the default directive, or add the line from the example to the
httporserverblock. - Test the configuration with
nginx -t, which shows whether OpenSSL accepted the group name, and reload the service. - Check from a client that a hybrid group was negotiated.
# nginx.conf, http or server block
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;
# in the terminal
nginx -t && systemctl reload nginx
openssl s_client -connect example.com:443 -groups X25519MLKEM768 </dev/nullThe classical X25519 and prime256v1 are left in the list: clients without post-quantum support will negotiate them. If the server does not support the hybrid group, the handshake with this command fails — that is the check. In the output look for the line Negotiated TLS1.3 group or Server Temp Key. The other directives are covered in the article on configuring SSL/TLS in nginx.
SSH: which OpenSSH version does what
Post-quantum exchange arrived in OpenSSH in two stages, and they must not be mixed up. In 9.9 the mlkem768x25519-sha256 algorithm became available by default, and it began to be used by default only in 10.0. If you run version 10.0 or newer, you do not need to enable anything.
| OpenSSH version | What changed |
|---|---|
| 9.0 | the default exchange became sntrup761x25519-sha512@openssh.com |
| 9.9 | the hybrid mlkem768x25519-sha256 (ML-KEM per FIPS 203 plus X25519) was added, available by default |
| 10.0 | mlkem768x25519-sha256 is used by default |
| 10.1 | ssh warns when a non-post-quantum exchange is negotiated; the option WarnWeakCrypto, on by default |
If the server offers no post-quantum algorithm at all, every client from 10.1 onward will see the warning. According to the page openssh.com/pq.html, the right fix is to update the server to an SSH implementation that has at least one such algorithm.
How to enable and verify post-quantum exchange in SSH
The check is a few commands: the client version, the list of supported exchanges, and the exchange chosen in verbose output; on the server, sshd -T shows the result. On version 10.0 and newer you need to enable nothing, unless you overrode the list by hand.
ssh -V
ssh -Q kex | grep -E "mlkem|sntrup"
sshd -T | grep -i kexalgorithms
ssh -v user@server.example 2>&1 | grep -i "kex: algorithm"An explicit order in sshd_config is set with the line KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512@openssh.com,curve25519-sha256. Before reloading, test the configuration with sshd -t and keep a second session open. The other daemon settings are covered in the article on hardening an SSH server.
Caveats: what can go wrong
The main trap is leaving only post-quantum algorithms in the setting. Then clients that do not know them stop connecting. This follows from how algorithms are negotiated; it is not a quotation from the documentation. So do not remove the classical fallback from the list until you are sure that all your clients are up to date.
If a proxy, load balancer or CDN stands in front of the server, the node that terminates TLS negotiates the group.
Frequently asked questions
Do I need to change my certificate for post-quantum TLS?
No. The key exchange and the certificate are different parts of the handshake. The X25519MLKEM768 hybrid changes the first, and the certificate stays as it was.
Why does ssh say the connection is not post-quantum?
This is how OpenSSH behaves from version 10.1 when a non-post-quantum exchange is negotiated; the WarnWeakCrypto option is on by default. Look for the cause on the server: update it rather than silencing the warning.
What should ZevsHost customers do?
On shared hosting the provider’s server decides the OpenSSL version and the TLS settings, so post-quantum key agreement cannot be switched on there — it is not the customer’s to change. The decision is yours on a VPS or dedicated server, where the OpenSSL, nginx and OpenSSH versions belong to you: start the check there.