Post-Quantum Cryptography: Preparing Your Website for Quantum-Safe TLS

What is Post-Quantum Cryptography?

Post-quantum cryptography (PQC) refers to cryptographic algorithms designed to be secure against attacks by both classical computers and quantum computers. Unlike current algorithms like RSA and elliptic curve cryptography (ECC), which rely on mathematical problems that quantum computers can solve efficiently, PQC algorithms are based on problems believed to be hard for both classical and quantum computers.

The security of the internet—including every HTTPS connection, every SSL/TLS certificate, and every encrypted email—depends on cryptographic algorithms that will eventually be broken by quantum computers. This isn't a distant threat; it's a present concern that security professionals worldwide are actively addressing.

In August 2024, the U.S. National Institute of Standards and Technology (NIST) published the first three post-quantum cryptographic standards after an 8-year evaluation process. These standards—ML-KEM, ML-DSA, and SLH-DSA—represent the foundation of quantum-safe cryptography that will protect the internet for decades to come.

For a deeper understanding of how current encryption works and why it's vulnerable, see our guides on How SSL Works and What is PKI.

The Quantum Threat to Current Encryption

How Quantum Computers Break Classical Cryptography

Current public-key cryptography relies on two mathematical problems:

• Integer Factorization (RSA): Difficulty of factoring large numbers into prime factors. RSA-2048 uses a 617-digit number.
• Discrete Logarithm (ECDH, ECDSA): Difficulty of computing logarithms in finite fields and elliptic curve groups.

These problems are computationally infeasible for classical computers—breaking RSA-2048 would take billions of years. However, Shor's algorithm, running on a sufficiently powerful quantum computer, can solve both problems in polynomial time. A quantum computer with approximately 4,000 stable, error-corrected qubits could break RSA-2048 in hours.

The "Harvest Now, Decrypt Later" Threat

Even though large-scale quantum computers don't exist yet, a critical threat is already active: adversaries can record encrypted traffic today and store it for decryption when quantum computers become available. This is known as "harvest now, decrypt later" (HNDL) or "store now, decrypt later" (SNDL).

If your website handles any data that should remain confidential for 10+ years, enabling post-quantum TLS today protects against future decryption by quantum computers.

Timeline Estimates

NIST Post-Quantum Cryptography Standards

After an 8-year international competition evaluating 82 candidate algorithms, NIST published three post-quantum cryptography standards in August 2024:

All three standards are based on mathematical problems believed to be resistant to quantum attacks. ML-KEM and ML-DSA use lattice-based cryptography, while SLH-DSA uses hash-based cryptography.

Understanding ML-KEM (Key Encapsulation)

ML-KEM (Module-Lattice Key Encapsulation Mechanism), formerly known as CRYSTALS-Kyber, replaces the key exchange portion of TLS. When you visit an HTTPS website, key exchange establishes the shared secret used to encrypt your session. Currently, this uses ECDH (Elliptic Curve Diffie-Hellman), which quantum computers can break.

How ML-KEM Works

ML-KEM is based on the Module Learning With Errors (MLWE) problem—finding a secret vector when given noisy linear combinations. This problem is believed to be hard for both classical and quantum computers.

1. Server generates ML-KEM key pair (public key ~1,184 bytes)
2. Server sends public key to client during TLS handshake
3. Client encapsulates: creates shared secret + ciphertext
4. Client sends ciphertext to server (~1,088 bytes)
5. Server decapsulates: recovers shared secret from ciphertext
6. Both parties now share identical 256-bit secret for AES encryption

ML-KEM Security Levels

For comparison, X25519 (current standard) has 32-byte public keys and 32-byte shared secrets. ML-KEM-768 keys are ~37x larger, but this is acceptable for most TLS use cases where bandwidth isn't severely constrained.

Understanding ML-DSA (Digital Signatures)

ML-DSA (Module-Lattice Digital Signature Algorithm), formerly CRYSTALS-Dilithium, replaces RSA and ECDSA signatures used for certificate authentication and data integrity. Every SSL certificate contains a digital signature from the Certificate Authority—these will eventually need to use quantum-safe algorithms.

How ML-DSA Works

ML-DSA is also based on the Module Learning With Errors problem, combined with the "Fiat-Shamir with Aborts" paradigm to create a secure signature scheme. The algorithm:

• Sign: Create a signature proving you possess the private key
• Verify: Confirm signature is valid using only the public key
• Non-repudiation: Signer cannot deny creating the signature

ML-DSA Security Levels

ML-DSA signatures are significantly larger than ECDSA (64 bytes) or RSA-2048 (256 bytes). This impacts certificate sizes and TLS handshake data, but modern networks handle this well.

Hybrid Cryptography: The Transition Strategy

Hybrid cryptography combines classical and post-quantum algorithms in a single protocol. This approach provides security guarantees from both algorithm families:

• If the classical algorithm (ECDH) is broken by quantum computers → PQ algorithm (ML-KEM) still protects
• If the PQ algorithm has undiscovered weaknesses → classical algorithm provides backup
• Both must be broken simultaneously to compromise the connection

X25519Kyber768 (Current Hybrid Standard)

The most widely deployed hybrid key exchange combines X25519 (classical ECDH) with ML-KEM-768 (post-quantum). This is identified in TLS as X25519Kyber768 or similar names.

Shared Secret = HKDF(X25519_shared_secret || ML-KEM-768_shared_secret)

Both components must be compromised to break the exchange:
- X25519: 32-byte keys, ~128-bit classical security
- ML-KEM-768: ~1,184-byte keys, ~192-bit quantum security

Combined: Protection against all known classical AND quantum attacks

Browser and Server Support

Preparing Your Website for Quantum-Safe TLS

Step 1: Assess Your Current Configuration

Use our SSL Checker to verify your current TLS configuration. Note your:

• TLS version (should be 1.2 or 1.3)
• Key exchange algorithms (ECDHE, DHE)
• Certificate signature algorithm (RSA, ECDSA)
• Server software version (OpenSSL, BoringSSL, etc.)

Step 2: Update Your TLS Library

Post-quantum TLS requires updated cryptographic libraries:

# Check current OpenSSL version
openssl version

# For PQ support, you need:
# OpenSSL 3.2+ with oqs-provider
# OR BoringSSL with PQ support
# OR AWS-LC (LibCrypto)

Step 3: Enable Hybrid Key Exchange

For Nginx with OpenSSL 3.2+:

# nginx.conf
ssl_ecdh_curve X25519Kyber768:X25519:P-256;

# This prioritizes hybrid PQ, falling back to classical for older clients

For Apache with OpenSSL 3.2+:

# httpd-ssl.conf
SSLOpenSSLConfCmd Groups X25519Kyber768:X25519:P-256

Step 4: Use a CDN with PQ Support

The easiest path to quantum-safe TLS is using a CDN that handles it automatically:

• Cloudflare: Automatic PQ TLS for all plans
• AWS CloudFront: Available with configuration
• Google Cloud CDN: PQ support in development

Testing Post-Quantum TLS Support

Test Your Server

# Test with OpenSSL (if PQ-enabled)
openssl s_client -connect yourdomain.com:443 -groups X25519Kyber768

# Look for output containing:
# Server Temp Key: X25519Kyber768

# Test with curl (verbose)
curl -v https://yourdomain.com 2>&1 | grep -i "SSL connection"

# Check negotiated cipher
openssl s_client -connect yourdomain.com:443 2>&1 | grep "Cipher is"

Browser Testing

In Chrome DevTools (F12) → Security tab, check the "Connection" section for the negotiated key exchange. If it shows "X25519Kyber768" or similar, your connection is using hybrid post-quantum TLS.

Timeline and Migration Roadmap