Post-quantum: TLS and NTS#

Why#

A sufficiently powerful quantum computer would break, in polynomial time, the public-key algorithms TLS relies on today (RSA, ECDSA/ECDHE), that’s Shor’s algorithm (1994). No current machine has the stability needed to pull this off at realistic key sizes, but the concrete threat isn’t in the future: it’s already here, in the form of the “harvest now, decrypt later” attack. An adversary can record encrypted traffic intercepted today, and decrypt it in ten or twenty years once a quantum computer is available. For a server meant to run long-term, guarding against this now is worthwhile, even if nobody is actively spying on this traffic today. This is no longer a niche topic: in May 2026, under the French presidency of the G7 and under ANSSI’s aegis, the G7 Cybersecurity Working Group made the post-quantum transition one of its declared priorities, judging that public and private organizations can no longer afford to keep postponing it.

Let’s be honest about the actual stakes. Applied to NTP/NTS traffic specifically, the “harvest now, decrypt later” scenario is a bit comical taken literally: the value of an encrypted record saying “it was 2:37:22 PM on March 12th” decrypted fifteen years from now is… close to zero. It’s nothing like intercepting medical records or diplomatic cables. This chapter’s real motivation isn’t “protecting a critical secret”, but demonstrating that reaching post-quantum state of the art is accessible, even on a project scoped for hobbyist use, the same cryptographic hygiene protects other things too (SSH in particular, where session content has genuine value), and once understood, costs just one configuration line. A 2023 ANSSI survey of its beneficiaries (large organizations and regulated operators) found that more than half are already exposed to the threat without knowing it, and that nearly all of them have neither a transition plan nor an identified deadline, for lack of resources or understanding of the stakes (ANSSI, Étude sur la transition post-quantique, March 2025): the configuration line below goes, quite concretely, further than what many large organizations have achieved to date.

This guide does not aim for exhaustiveness on security. This chapter covers one specific mechanism (the hybrid key exchange), not a complete cryptographic policy. See the Lynis chapter for a broader audit approach.

How: the hybrid key exchange#

The industry’s chosen defense isn’t to replace classical cryptography with post-quantum, but to combine them:

X25519MLKEM768 = ML-KEM-768 ‖ X25519

The final shared secret is derived from the concatenation of two secrets, the post-quantum KEM ML-KEM-768 (formerly CRYSTALS-Kyber, NIST FIPS 203) and the classical X25519 elliptic-curve exchange, fed into TLS 1.3’s key schedule. The resulting security property is simple and robust: the combined secret stays indistinguishable from random as long as at least one of the two mechanisms remains secure.

 If ML-KEM-768 has a flaw       → X25519 saves the day
 If X25519 is broken (quantum)  → ML-KEM-768 saves the day
 Both must be broken simultaneously to compromise the exchange

Enabling the hybrid for the web page#

ssl_ecdh_curve X25519MLKEM768:X25519:secp256r1;

This list’s order is a descending preference list, not an arbitrary enumeration: nginx offers X25519MLKEM768 first, and only falls back to X25519 (classical, but fast and widely supported) then secp256r1 (a NIST curve, the most universally compatible) if the client can’t negotiate the previous option. An older client keeps working without disruption, while getting the post-quantum hybrid as soon as it supports it. ANSSI details this mechanism and recommends this hybridization in its technical note Transition post-quantique de TLS 1.3 (ANSSI-FT-115, February 2026).

# Check whether a server actually negotiates the hybrid group
openssl s_client -connect time.example.org:443 -groups X25519MLKEM768 </dev/null 2>/dev/null \
    | grep "Negotiated TLS1.3 group"
# Expected: "Negotiated TLS1.3 group: X25519MLKEM768"

Enabling the hybrid for SSH#

# In /etc/ssh/sshd_config.d/99-hardening.conf (SSH hardening chapter)
KexAlgorithms mlkem768x25519-sha256,curve25519-sha256@libssh.org,...

The same hybridization, applied this time to SSHv2’s Transport Layer protocol, is detailed by ANSSI in its technical note Transition post-quantique de SSHv2 (ANSSI-FT-116, February 2026).

Pitfalls to avoid#

Don’t expect NTS-KE to negotiate the post-quantum hybrid today, even with an up-to-date nginx and OpenSSL. This is the chapter’s most counter-intuitive trap: nginx and the HTTPS web page can negotiate X25519MLKEM768 as soon as OpenSSL ≥ 3.5 is available, but chrony doesn’t delegate its TLS layer to OpenSSL: it uses GnuTLS. Availability of the hybrid group for chrony’s NTS-KE therefore depends first on the bundled GnuTLS version (and the priority chain it exposes), not just on chrony’s version. As of this guide’s writing, chrony 4.6.x only negotiates classical ECDHE groups (X25519, secp256r1) for NTS-KE. Verify the actual state before assuming post-quantum protection is in place on the NTS traffic itself.

Confusing “post-quantum certificate” with “post-quantum key exchange”. No public certificate authority (Let’s Encrypt included) currently issues certificates signed with a post-quantum algorithm (ML-DSA, SLH-DSA), the public X.509 ecosystem isn’t ready for that yet, despite NIST having standardized these signature algorithms. This chapter is only about the key exchange (KEM), which protects session confidentiality, not the certificate’s own chain of trust.
Neglecting the SSH layer as “just administration”. SSH traffic intercepted and stored today (typed commands, occasionally secrets shown on screen) is just as exposed to harvest now, decrypt later as web traffic. OpenSSH ≥ 9.9 supports mlkem768x25519-sha256, enabling it costs one configuration line.

Verify#

# Web: is the hybrid group offered and negotiated?
openssl s_client -connect time.example.org:443 -groups X25519MLKEM768 </dev/null 2>/dev/null \
    | grep "Negotiated TLS1.3 group"

# SSH: which KEX are actually active?
ssh -Q kex | grep mlkem
sshd -T | grep -i kexalgorithms

# NTS-KE: observe the current state (likely classical, not hybrid)
openssl s_client -connect time.example.org:4460 </dev/null 2>/dev/null

This chapter isn’t meant to stay frozen: post-quantum availability evolves quickly (GnuTLS, chrony, OpenSSL versions). What matters is the verification method above, not today’s conclusion: these commands should be rerun periodically rather than assuming today’s answer still holds a year from now. This posture matches what ANSSI formalizes under the name crypto-agility: letting several mechanisms coexist and being able to switch to the more robust one without breaking the service, rather than freezing a choice once and for all (ANSSI, ANSSI’s views on crypto-agility, 2026). This guide’s KexAlgorithms/ssl_ecdh_curve lists, post-quantum hybrid first with a classical fallback on incompatibility, are a direct instance of it.

📚 Going further
Shor’s algorithm (P. Shor, 1994) breaks RSA and ECDSA in polynomial time on a sufficiently large quantum computer.
The NIST Post-Quantum Cryptography Standardization Process (2016-2024) selected ML-KEM (formerly CRYSTALS-Kyber, FIPS 203) for key encapsulation, and ML-DSA (formerly Dilithium, FIPS 204) / SLH-DSA (formerly SPHINCS+, FIPS 205) for signatures.
The general construction of the hybrid exchange is specified by the IETF (draft-ietf-tls-hybrid-design); the concrete X25519MLKEM768 group used here is defined by draft-ietf-tls-ecdhe-mlkem.
RFC 8446 (TLS 1.3) and RFC 8915 (NTS) remain the transport protocols this hybrid mechanism attaches to, see the NGINX/NTS and Chrony chapters for the protocol itself.
ANSSI, Transition post-quantique de TLS 1.3 (ANSSI-FT-115) and Transition post-quantique de SSHv2 (ANSSI-FT-116), February 2026: the technical notes this chapter’s hybridization recommendations are drawn from.
ANSSI, ANSSI’s views on crypto-agility, 2026: the general framework (parameter tuning vs. algorithm replacement, static vs. upgradable mechanisms) behind the recommendation to never freeze a cryptographic choice.
ANSSI, Étude sur la transition post-quantique (a survey of ANSSI’s beneficiaries), March 2025: a snapshot, still very much behind, that puts into perspective what this chapter achieves with one configuration line.
cyber.gouv.fr, “Cryptographie post-quantique” dossier and its dedicated FAQ, for a broader introduction than this chapter.