Post-Quantum Cryptography: Is Your TLS Quantum-Safe?

The Quantum Threat to Current Encryption

Every TLS connection on the internet today relies on mathematical problems that classical computers cannot solve efficiently. RSA depends on the difficulty of factoring large numbers. Elliptic curve cryptography (ECDHE, ECDSA) depends on the discrete logarithm problem over elliptic curves. These problems have resisted decades of classical attacks, which is why they form the foundation of internet security.

Quantum computers change the equation. Shor's algorithm, running on a sufficiently powerful quantum computer, can factor large numbers and solve discrete logarithm problems in polynomial time. This means RSA, ECDHE, ECDSA, and DSA -- the algorithms protecting virtually every TLS connection today -- would all be broken.

The timeline for quantum computers reaching this capability is debated, but the consensus among cryptographers and intelligence agencies is that it falls within the 2030-2040 window. Some estimates are more aggressive. The exact date matters less than the implication: data encrypted today with vulnerable algorithms can be recorded and decrypted later when quantum computers become available.

This is the "harvest now, decrypt later" threat. Nation-state adversaries and sophisticated attackers are already collecting encrypted traffic with the expectation of decrypting it in the future. For data with long confidentiality requirements -- healthcare records, financial data, trade secrets, government communications -- the quantum threat is not a future problem. It is a present one.

NIST Post-Quantum Standards

The National Institute of Standards and Technology (NIST) has been running a post-quantum cryptography standardization process since 2016, evaluating candidate algorithms submitted by research teams worldwide. In 2024, NIST finalized its first three post-quantum standards:

ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism), formerly known as CRYSTALS-Kyber, standardized as FIPS 203. This is the recommended algorithm for key exchange in TLS connections. It replaces the key agreement step currently handled by ECDHE.

ML-DSA (Module-Lattice-Based Digital Signature Algorithm), formerly CRYSTALS-Dilithium, standardized as FIPS 204. This provides digital signatures for authentication, replacing RSA and ECDSA signatures in certificates and handshakes.

SLH-DSA (Stateless Hash-Based Digital Signature Algorithm), formerly SPHINCS+, standardized as FIPS 205. This is a backup signature algorithm based on hash functions rather than lattice mathematics, providing algorithm diversity in case lattice-based schemes are found to be vulnerable.

These standards are based on lattice problems and hash functions, which are believed to be resistant to both classical and quantum attacks. They are not theoretical -- implementations exist in major cryptographic libraries, and browser vendors and server software are already integrating support.

What This Means for TLS

The transition to post-quantum TLS involves changes at multiple layers of the connection.

Key exchange is the most urgent component. The TLS handshake uses key agreement (currently ECDHE) to establish a shared secret between client and server. If an attacker records the handshake and the encrypted session, they can later use a quantum computer to recover the shared secret and decrypt the entire session. This is why "harvest now, decrypt later" targets key exchange specifically.

The solution is hybrid key exchange, which combines a classical algorithm (like X25519) with a post-quantum algorithm (like ML-KEM-768) in the same handshake. If either algorithm remains secure, the connection is protected. Chrome, Firefox, and other browsers have begun supporting hybrid key exchange using X25519+ML-KEM-768 (previously called X25519Kyber768).

# TLS 1.3 key exchange groups (OpenSSL 3.x)
# Classical: x25519, secp256r1
# Hybrid PQ: x25519_mlkem768 (preferred)
ssl_conf_command Groups x25519_mlkem768:x25519:secp256r1

Authentication is less urgent for the "harvest now, decrypt later" scenario because authentication happens in real-time -- an attacker needs a quantum computer at the time of the connection, not later. However, certificates with long validity periods that will still be in use when quantum computers arrive should use post-quantum signatures. The transition to post-quantum certificate signatures will be gradual and depends on CA and browser support.

Handshake size increases significantly with post-quantum algorithms. ML-KEM-768 public keys are approximately 1,184 bytes, compared to 32 bytes for X25519. ML-DSA-65 signatures are approximately 3,293 bytes, compared to 64 bytes for ECDSA. This increase affects TLS handshake latency, particularly on constrained networks and devices. Hybrid key exchange roughly doubles the key exchange portion of the handshake.

Assessing Your Current TLS Configuration

Before planning a post-quantum migration, you need to understand your current TLS configuration. Several aspects of your existing setup indicate readiness or obstacles for the transition.

TLS version support is the first checkpoint. Post-quantum key exchange is only supported in TLS 1.3. If your servers still support TLS 1.2 as the primary version (or worse, TLS 1.0/1.1), upgrading to TLS 1.3 is a prerequisite. TLS 1.3 simplified the handshake, removed legacy cipher suites, and provides the extension framework needed for hybrid key exchange.

Key exchange algorithms currently in use indicate your cryptographic agility. If your servers are configured to use ECDHE (specifically X25519 or P-256), the transition path is clear -- hybrid key exchange adds the post-quantum component alongside the existing classical algorithm. If your servers still rely on RSA key exchange (which TLS 1.3 removed), you have a longer migration path.

Certificate key types matter for the authentication transition. RSA-2048 and RSA-4096 certificates are the most common today. ECDSA (P-256 or P-384) certificates are more modern and indicate an organization that has already navigated one cryptographic transition. Organizations comfortable with ECDSA certificates will find the eventual move to ML-DSA certificates more familiar.

Cipher suite configuration reveals overall cryptographic hygiene. Servers that still offer weak ciphers (RC4, DES, 3DES, export-grade) have not been maintained for cryptographic best practices. Our TLS protocol and cipher hardening guide details how to configure strong cipher suites as a prerequisite before considering post-quantum upgrades.

CyberShield's TLS module evaluates all of these aspects. The scan reports which TLS versions your server supports, which key exchange groups are offered, what cipher suites are configured, and what certificate types are in use. This data provides a clear picture of your current position and what needs to change.

The Hybrid Transition Approach

The cryptographic community has converged on a hybrid approach for the post-quantum transition. Rather than replacing classical algorithms with post-quantum algorithms in a single step, hybrid schemes combine both.

Why hybrid? Post-quantum algorithms are newer and have received less cryptographic analysis than established algorithms. While the NIST standardization process was rigorous, the possibility exists that a vulnerability could be discovered in a lattice-based scheme. A hybrid approach ensures that if the post-quantum component is broken, the classical component still provides protection. Conversely, if quantum computers arrive sooner than expected, the post-quantum component provides protection even though the classical component is broken.

Browser support for hybrid key exchange is advancing rapidly. Chrome enabled X25519+ML-KEM-768 by default starting in late 2024. Firefox followed with support in its release cycle. These browsers negotiate hybrid key exchange automatically when the server supports it.

Server support varies by software:

For Nginx with OpenSSL 3.5+:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ecdh_curve x25519_mlkem768:X25519:prime256v1;

For Apache with OpenSSL 3.5+:

SSLOpenSSLConfCmd Groups x25519_mlkem768:X25519:prime256v1

Compatibility considerations: Not all clients support hybrid key exchange. Older browsers, embedded devices, API clients using older TLS libraries, and some corporate proxies may not recognize post-quantum key exchange groups. Servers should list hybrid groups first (preferred) with classical fallbacks, ensuring that clients negotiate the strongest mutually supported option.

Some middleboxes (firewalls, IDS/IPS, TLS inspection proxies) have been observed to reject TLS handshakes with post-quantum key exchange because the larger ClientHello message exceeds expected size limits. This is a known deployment issue that is being addressed by vendors, but organizations should test their infrastructure before enabling hybrid key exchange in production.

What CyberShield Checks

CyberShield's TLS module provides the data you need to assess quantum readiness:

Protocol version support shows whether TLS 1.3 is enabled. Since post-quantum key exchange requires TLS 1.3, servers limited to TLS 1.2 cannot participate in hybrid key exchange even if the underlying cryptographic library supports it.

Key exchange groups report which named groups the server offers. The presence of X25519 indicates modern elliptic curve support. As server software and CyberShield's detection evolve, hybrid groups (X25519+ML-KEM-768) will be tracked alongside classical groups.

Cipher suite analysis identifies whether the server is using authenticated encryption (AES-GCM, ChaCha20-Poly1305) with forward secrecy. These are the cipher suites that pair with post-quantum key exchange in TLS 1.3.

Certificate details report the key type (RSA vs ECDSA), key size, signature algorithm, and validity period. This data helps plan the eventual transition to post-quantum certificate signatures.

Preparing Your Organization

The post-quantum transition is not something you need to complete tomorrow, but it is something you should begin planning now.

Immediate actions:

• Ensure all servers support TLS 1.3 (prerequisite for PQ key exchange)
• Disable TLS 1.0 and 1.1 if you have not already
• Remove weak cipher suites and ensure forward secrecy is enabled
• Run a TLS audit to baseline your current configuration and identify gaps

Near-term (6-12 months):

• Inventory all TLS endpoints, including those managed by third parties (CDNs, cloud services, SaaS platforms)
• Test hybrid key exchange in staging environments
• Identify middleboxes that may interfere with larger TLS handshakes
• Verify that your certificate authority supports the latest key types

Medium-term (1-2 years):

• Enable hybrid key exchange on production servers where client compatibility allows
• Monitor browser and client support for post-quantum algorithms
• Plan for post-quantum certificate signatures as CA support matures

Long-term (2-5 years):

• Complete migration to hybrid or fully post-quantum key exchange across all endpoints
• Transition to post-quantum certificate signatures as standards and tooling mature — use the certificate lifecycle management checklist to plan certificate migration at scale
• Decommission purely classical key exchange for sensitive workloads

The organizations that begin this assessment now will have a smooth transition. Those that wait until quantum computers are imminent will face a rushed, error-prone migration under pressure. Cryptographic transitions take years across large infrastructures -- the time to start is before it becomes urgent.