In August 2024, NIST published its first three post-quantum cryptographic standards: FIPS 203 (ML-KEM, based on CRYSTALS-Kyber), FIPS 204 (ML-DSA, based on CRYSTALS-Dilithium), and FIPS 205 (SLH-DSA, based on SPHINCS+). The publication marked the conclusion of an eight-year standardization effort that began in 2016 and evaluated 82 candidate algorithms from research teams worldwide. The standards are not theoretical. They are production specifications, with mandated federal adoption timelines and immediate implications for every organization that depends on public-key cryptography — which is every organization that operates in the cloud.

The urgency is not driven by the existence of a cryptographically relevant quantum computer today. No such machine exists. IBM’s 1,121-qubit Condor processor, unveiled in December 2023, and Google’s 105-qubit Willow chip are significant engineering achievements, but they operate with error rates far too high for Shor’s algorithm to break RSA-2048 or elliptic curve cryptography. Current estimates for a cryptographically relevant quantum computer — one with enough stable, error-corrected logical qubits to run Shor’s algorithm against 2048-bit RSA — range from 2030 to 2040, depending on the source and the assumptions about error correction advances.

The urgency is driven by a different threat: harvest now, decrypt later (HNDL). A state-level adversary intercepting encrypted traffic today can store the ciphertext indefinitely and decrypt it once a quantum computer becomes available. If a conversation encrypted with ECDH P-256 is intercepted in 2026 and a quantum computer capable of breaking P-256 appears in 2034, the conversation is retroactively exposed — eight years after it occurred. For data with long-term sensitivity (state secrets, medical records, legal communications, corporate strategy), the quantum threat is not a future problem. It is a present collection operation.

The Cryptographic Exposure

Modern cloud infrastructure depends on public-key cryptography for three critical functions: key exchange, digital signatures, and certificate validation. Each is vulnerable to quantum attack.

Key Exchange: The HNDL Target

TLS 1.3 — the protocol protecting virtually all cloud API traffic — uses Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) for key exchange. The security of ECDHE rests on the hardness of the Elliptic Curve Discrete Logarithm Problem (ECDLP). Shor’s algorithm solves ECDLP in polynomial time on a quantum computer.

An adversary performing HNDL collection against TLS 1.3 traffic needs to capture only the initial handshake (specifically, the public key shares in the ClientHello and ServerHello messages) and the subsequent encrypted traffic. Once they can solve the ECDLP for the key exchange, they recover the session key and decrypt all traffic in that session.

TLS 1.3’s use of ephemeral keys provides forward secrecy against classical attackers — compromising the server’s long-term private key does not compromise past sessions. But forward secrecy does not protect against HNDL: each session’s ephemeral key exchange is recorded by the adversary and will be broken individually by the quantum computer. Every TLS session becomes a stored liability.

The NSA’s 2022 CNSA 2.0 guidance explicitly acknowledged the HNDL threat, mandating that all National Security Systems adopt quantum-resistant key exchange by 2030 and quantum-resistant digital signatures by 2033. The split timeline reflects the relative urgency: key exchange protects confidentiality (vulnerable to retroactive decryption via HNDL), while digital signatures protect authenticity (only vulnerable at the moment of verification, making retroactive attack less practical).

Digital Signatures: The Infrastructure Target

RSA and ECDSA signatures secure the certificate chain from root CAs to leaf certificates, authenticate software packages and container images, validate blockchain transactions and wallet signatures, and authorize API calls in zero-trust architectures.

A quantum computer capable of breaking ECDSA would compromise the Sign-In with Ethereum authentication model, since SIWE relies on secp256k1 ECDSA signatures. It would also compromise every existing TLS certificate, every signed software artifact, and every digitally signed document. The impact is broader than confidentiality — it is an integrity crisis.

However, signatures are less vulnerable to HNDL because their security matters at the moment of verification, not retroactively. A forged signature is only useful if the attacker can present it to a verifier in real time. This is why CNSA 2.0 gives digital signatures a three-year longer migration window than key exchange.

Symmetric Cryptography: The Survivor

AES-256-GCM — the symmetric encryption standard used for data encryption — is not broken by Shor’s algorithm. Grover’s algorithm provides a quadratic speedup for brute-force search of symmetric keys, effectively halving the security level: AES-256 becomes AES-128 against a quantum attacker. AES-128 against Grover’s algorithm provides approximately 64 bits of security — insufficient. AES-256 against Grover’s algorithm provides approximately 128 bits — still within the range considered secure by NIST.

This means that data encrypted with AES-256 today remains quantum-resistant, provided the key was established through a quantum-resistant key exchange mechanism. The vulnerability is not in the symmetric cipher but in the key exchange that establishes the symmetric key. Fixing the key exchange fixes the system.

The NIST Post-Quantum Standards

ML-KEM (FIPS 203): Key Encapsulation

ML-KEM (Module Lattice-based Key Encapsulation Mechanism), standardized from CRYSTALS-Kyber, replaces ECDHE for key exchange. It is based on the Module Learning With Errors (MLWE) problem — a lattice problem for which no efficient quantum algorithm is known.

ML-KEM operates as a Key Encapsulation Mechanism (KEM) rather than a Diffie-Hellman-style key exchange. The difference is protocol-level: in a KEM, one party generates a shared secret and encapsulates it under the other party’s public key. In DH, both parties contribute to the shared secret derivation. The practical impact is minimal for most protocols, but KEM integration requires protocol changes in TLS, SSH, and IKEv2.

NIST defined three parameter sets:

  • ML-KEM-512: 128-bit security. Public key: 800 bytes. Ciphertext: 768 bytes.
  • ML-KEM-768: 192-bit security. Public key: 1,184 bytes. Ciphertext: 1,088 bytes.
  • ML-KEM-1024: 256-bit security. Public key: 1,568 bytes. Ciphertext: 1,568 bytes.

For comparison, an ECDH P-256 public key is 65 bytes and the key share in TLS is 69 bytes. ML-KEM-768 increases the key exchange payload by approximately 15x. In TLS 1.3, this adds roughly 2 KB to the ClientHello and ServerHello messages — a meaningful increase for latency-sensitive applications, particularly on mobile networks.

Performance benchmarks on modern hardware (Intel Core i7-13700K) show ML-KEM-768 key generation at approximately 65 microseconds, encapsulation at 85 microseconds, and decapsulation at 80 microseconds. ECDH P-256 key generation takes approximately 30 microseconds and shared secret derivation approximately 120 microseconds. ML-KEM is faster than ECDH for the combined key exchange operation, despite the larger key sizes.

ML-DSA (FIPS 204): Digital Signatures

ML-DSA (Module Lattice-based Digital Signature Algorithm), standardized from CRYSTALS-Dilithium, replaces RSA and ECDSA for digital signatures.

  • ML-DSA-44: 128-bit security. Public key: 1,312 bytes. Signature: 2,420 bytes.
  • ML-DSA-65: 192-bit security. Public key: 1,952 bytes. Signature: 3,293 bytes.
  • ML-DSA-87: 256-bit security. Public key: 2,592 bytes. Signature: 4,595 bytes.

ECDSA P-256 signatures are 64 bytes. RSA-2048 signatures are 256 bytes. ML-DSA-65 signatures are approximately 3.3 KB — 13x larger than RSA and 51x larger than ECDSA. For certificate chains (which typically contain 2-3 certificates, each with a signature and a public key), the increase is substantial: a TLS certificate chain could grow from approximately 3 KB to approximately 20 KB.

For blockchain and wallet-based authentication, the signature size increase has protocol implications. Ethereum transactions currently use 65-byte secp256k1 signatures. A post-quantum Ethereum would need to accommodate signatures 50x larger, with corresponding impacts on gas costs, block size, and transaction throughput.

SLH-DSA (FIPS 205): Stateless Hash-Based Signatures

SLH-DSA (Stateless Lattice-based Hash Digital Signature Algorithm), based on SPHINCS+, provides a conservative backup signature scheme based entirely on hash functions rather than lattice assumptions. If the MLWE problem is broken (a theoretical possibility, however unlikely), SLH-DSA remains secure as long as the underlying hash function (SHA-256 or SHAKE-256) is secure.

The cost of this conservatism is size: SLH-DSA-128f signatures are approximately 17 KB — roughly 5x larger than ML-DSA-65. Verification is also significantly slower. SLH-DSA is intended as a hedge against mathematical breakthroughs in lattice cryptography, not as the primary migration target.

The Migration Challenge

Hybrid Key Exchange

The industry consensus for the transition period is hybrid key exchange: combining a classical algorithm (ECDH) with a post-quantum algorithm (ML-KEM) so that the session is secure as long as either algorithm remains unbroken. If ML-KEM is discovered to have a vulnerability, ECDH still protects against classical attackers. If a quantum computer breaks ECDH, ML-KEM still protects against quantum attackers.

Chrome and Firefox have implemented hybrid key exchange (X25519MLKEM768) in TLS 1.3 since 2024. Cloudflare enabled support across its network in early 2025, reporting that approximately 15% of TLS connections to Cloudflare now use hybrid key exchange. The adoption is limited primarily by server-side support — many CDNs, load balancers, and API gateways have not yet updated their TLS stacks.

Certificate Chain Migration

Migrating certificate chains is more complex than migrating key exchange. Certificate chains are embedded in long-lived artifacts (signed binaries, timestamped documents, blockchain transactions) and are validated by heterogeneous verifiers (browsers, operating systems, IoT devices) with varying update cadences.

A root CA that issues ML-DSA certificates must wait for all relying parties to support ML-DSA verification before those certificates are useful. The browser ecosystem can update in months. Enterprise CA hierarchies take years. IoT devices with firmware-locked trust stores may never support post-quantum signatures.

The proposed solution is hybrid certificates: certificates containing both a classical signature and a post-quantum signature. Verifiers that support ML-DSA validate the post-quantum signature. Verifiers that don’t fall back to the classical signature. The cost is certificate bloat — a hybrid certificate is approximately 10 KB larger than a classical certificate.

Code Signing and Software Supply Chain

Every container image, npm package, Python wheel, and firmware binary authenticated by RSA or ECDSA signatures will eventually need post-quantum equivalents. The migration timeline for software supply chains is governed by the longest-lived artifact: a signed firmware image deployed to an IoT device in 2026 may need to be verifiable in 2040. If the signing key is ECDSA, and a quantum computer breaks ECDSA before 2040, the firmware’s authenticity can no longer be verified.

Sigstore, the Linux Foundation’s software signing infrastructure, has begun publishing roadmaps for post-quantum signature support, but production deployment is not expected before 2028.

Quantum Threat to Specific Cloud Primitives

TLS Everywhere

Every API call, every microservice-to-microservice request, every database connection, every webhook — all protected by TLS, all using ECDHE key exchange that is vulnerable to HNDL. The aggregate volume of TLS traffic in a typical cloud deployment generates an enormous corpus for an adversary conducting HNDL collection.

The mitigation is hybrid TLS. For zero-trust architectures where every service-to-service connection is independently authenticated and encrypted, the migration to hybrid TLS must cover not just the external edge but every internal communication path.

Wallet Authentication

Ethereum’s secp256k1 ECDSA signatures — the foundation of SIWE-based authentication — are directly vulnerable to Shor’s algorithm. A quantum computer that can solve the ECDLP for secp256k1 can derive any wallet’s private key from its public key. Since Ethereum addresses are derived from public keys, and public keys are revealed in every transaction, every active Ethereum wallet with at least one outgoing transaction has an exposed public key.

The Ethereum community is actively researching account abstraction (EIP-4337) as a migration path, which would allow wallets to use quantum-resistant signature schemes without changing the address format. Vitalik Buterin’s 2024 post on “Quantum Emergency Recovery” proposed a hard fork contingency plan that would freeze all accounts and require users to prove knowledge of a pre-committed quantum-resistant key.

Object Storage and Key Management

AWS KMS, Google Cloud KMS, and Azure Key Vault use RSA or elliptic curve keys for envelope encryption — the pattern where a data encryption key (DEK) is encrypted by a key encryption key (KEK) stored in the KMS. If the KEK is RSA-2048, and an adversary captures the encrypted DEK (which is stored alongside the encrypted data in S3, GCS, or Azure Blob), a future quantum computer can recover the DEK and decrypt all associated data.

AWS began offering ML-KEM key agreement in KMS in late 2025, but the default remains RSA. Organizations that have stored encrypted data with RSA-wrapped DEKs for years are accumulating a quantum-vulnerable archive that grows daily.

The Zero-Persistence Quantum Defense

There is a defense against harvest-now-decrypt-later that does not require post-quantum cryptography: ensure there is nothing to harvest.

HNDL attacks require two conditions: the adversary must capture the ciphertext, and the ciphertext must still be relevant when the adversary can decrypt it. Ephemeral infrastructure attacks the second condition. If a conversation encrypted with ECDHE exists only for the 200 ms it takes to process a request, is never written to disk, never backed up, and the session keys are destroyed via cryptographic shredding immediately after, the adversary’s HNDL collection contains a ciphertext that decrypts to a single, stateless request with no user-identifying information (thanks to PII stripping) and no historical context.

The adversary invested resources in intercepting, storing, and eventually decrypting a single sanitized prompt. The return on that investment is near zero.

This is not a substitute for post-quantum migration. It is a complementary defense that reduces the value of HNDL collection to the point where the economics of the attack collapse. Even if the adversary breaks the key exchange, the data they recover is ephemeral, anonymized, and contextless.

Migration Priorities for Cloud Operators

The practical migration priority, based on the HNDL threat model:

  1. Immediate (2026). Enable hybrid key exchange (X25519MLKEM768) on all external-facing TLS endpoints. This protects new traffic against HNDL collection.
  2. Short-term (2026-2027). Migrate internal service-to-service TLS to hybrid key exchange. Evaluate ML-KEM support in cloud KMS services for new key material.
  3. Medium-term (2027-2029). Migrate certificate chains to hybrid or post-quantum signatures. Update code signing infrastructure.
  4. Long-term (2029-2033). Complete migration of all cryptographic operations to post-quantum standards. Retire classical-only key material.

For organizations with data that is already stored and encrypted with classical key exchange: the damage may already be done. If adversaries have collected the ciphertext, migrating to post-quantum cryptography going forward does not protect the historical data. The only remediation is to re-encrypt stored data with post-quantum key exchange — or to delete the stored data entirely, if the data retention policy permits.

The Stealth Cloud Perspective

Stealth Cloud’s cryptographic architecture is designed for a post-quantum world, even before that world fully arrives. The defense is layered and deliberate.

First, AES-256-GCM — our symmetric encryption standard for client-side message encryption — provides 128-bit security against Grover’s algorithm. Symmetric encryption is the foundation, and it survives the quantum transition intact.

Second, the key exchange layer — currently operating over Cloudflare’s network, which supports hybrid X25519MLKEM768 TLS — is migrating to post-quantum key agreement. As Cloudflare extends ML-KEM support across its Workers runtime, every Stealth Cloud session will negotiate quantum-resistant key exchange without any change to our application code.

Third, and most fundamentally: zero-persistence architecture is the strongest possible defense against harvest-now-decrypt-later. There is nothing to harvest. There is nothing to store. There is nothing to decrypt later. A conversation that existed only in volatile memory, was encrypted with client-held keys, had its PII stripped before reaching any server, and was cryptographically shredded upon session termination — that conversation is immune to retroactive decryption, because the ciphertext was never persisted and the keys were never stored.

Post-quantum cryptography is a necessary evolution for the entire industry. For infrastructure built on zero-persistence principles, it is the final layer of a defense that was already structurally resistant to the quantum threat. The organizations most exposed to harvest-now-decrypt-later are the ones sitting on years of stored, classically-encrypted data with no practical way to re-encrypt it. The organizations least exposed are the ones that never stored the data in the first place.