End-to-End Encryption: What It Protects Against Today and What Quantum Computers Will Break

Most coverage of quantum computers and encryption either catastrophises or dismisses. Quantum will break everything. Or: relax, it's decades away. Neither answer is useful, and neither is accurate.

The precise answer is this: a quantum computer would break the key exchange step of end-to-end encryption (E2EE), not the bulk message cipher. That distinction matters a great deal, because some E2EE systems are already protected against it, some are not, and the risk profile varies considerably depending on how the application was designed. This article works through the mechanics carefully so you can assess your own situation rather than rely on a headline.

What End-to-End Encryption Actually Does

End-to-end encryption is a scheme in which a message is encrypted on the sender's device and decrypted only on the recipient's device. The service provider in the middle, the messaging platform, the email server, the cloud storage operator, never holds the decryption key. It sees ciphertext. Even a subpoena to the service provider yields nothing readable.

This works because E2EE has two distinct cryptographic components, and it's important to keep them separate in your thinking.

The first is the key exchange. Before any messages are encrypted, the two parties need to agree on a shared secret, a key that will lock and unlock the messages. They cannot send this key over the network (an interceptor would capture it), so instead they use a mathematical protocol called Elliptic Curve Diffie-Hellman (ECDH) to derive a shared secret without either party transmitting it. Signal and WhatsApp both use Curve25519, a specific ECDH implementation. The key exchange establishes what the session key will be.

The second is the message cipher. Once the shared secret exists, messages are encrypted with AES-256 (or in some cases ChaCha20-Poly1305), fast, battle-tested symmetric encryption. The session key locks and unlocks message content. This is the bulk encryption that actually handles your text, files, and calls.

Signal's protocol adds a third layer on top of this: forward secrecy, implemented via its X3DH initial key agreement and Double Ratchet ongoing ratcheting. With forward secrecy, each session generates throwaway keys that are discarded after use. If an attacker compromises your long-term keys tomorrow, they cannot use them to decrypt messages from today's session, those session keys are already gone. WhatsApp uses the Signal Protocol and inherits the same properties.

What E2EE does not protect against: an adversary who controls your unlocked device (they read the plaintext directly, no cryptography required); metadata, who you message, when, and how often, which is typically visible to the service provider; and key verification failures, where a man-in-the-middle substitutes their own keys and you do not notice because you never checked the safety numbers.

These are classical limitations. They existed before anyone worried about quantum computers.

What a Quantum Computer Actually Breaks

A cryptographically relevant quantum computer (CRQC), one with enough scale and error correction to run attacks against current cryptographic systems, does not exist yet. The central estimate for when one might emerge is 2033 to 2035, though probability distributions vary and the field is moving faster than expected in some areas. The threat is not imminent in the sense of weeks or months. It is plausible within a planning horizon that matters for data with long sensitivity windows.

Two quantum algorithms are relevant here, and they threaten very different things.

Shor's algorithm (1994) can efficiently solve the discrete logarithm problem and the integer factorisation problem. These are the mathematical foundations of ECDH and RSA. An attacker running Shor's on a CRQC could compute the private key from the public key, reconstruct the shared secret, and decrypt any session key derived using ECDH or RSA. This breaks the key exchange component of E2EE. NIST IR 8547 (November 2024) formally designates ECDH for deprecation in new deployments from 2030 on precisely this basis. For a detailed explanation of how Shor's algorithm attacks RSA and ECC specifically, see Shor's algorithm: how it breaks RSA and ECC.

Grover's algorithm (1996) searches an unsorted database of N items in roughly √N operations rather than N. Applied to symmetric cryptography, it halves effective key security. AES-128 would have roughly 64 bits of effective security against a quantum computer, too weak. AES-256 would have roughly 128 bits, still considered computationally infeasible to attack with any technology currently known, classical or quantum.

The practical bottom line: a CRQC breaks the ECDH key exchange. It does not break AES-256 message encryption in any meaningful sense. Signal, WhatsApp, and iMessage use AES-256 (or ChaCha20) for message content. That part is not the problem.

The problem is the shared secret that was established using ECDH. If an attacker can reconstruct that secret, using a future CRQC running Shor's algorithm, they could potentially decrypt sessions where they captured the key exchange traffic.

The Harvest Now, Decrypt Later Risk

This is where the timeline gets uncomfortable. A CRQC does not need to exist today for the threat to be present today. An adversary can capture encrypted traffic now and decrypt it later, once the hardware arrives. This is Harvest Now, Decrypt Later (HNDL), and it is the mechanism that converts a theoretical future threat into a present operational risk for anyone with data worth protecting over a multi-year horizon.

For E2EE applications with forward secrecy, like Signal and WhatsApp, the HNDL risk is significantly reduced. Each session uses ephemeral ECDH keys that are discarded after the session ends. An adversary who captures ciphertext but not the ephemeral key exchange at the time of the session cannot retroactively reconstruct the session key, there is nothing to reconstruct from. Forward secrecy was designed for this kind of retrospective attack.

PGP email works differently and is materially more vulnerable. Standard OpenPGP (RFC 4880) uses a long-term RSA or ECDH key pair, the same private key decrypts every message ever sent to that address. An adversary who harvests PGP-encrypted email archives from 2024 and later obtains the RSA private key (whether through a CRQC or through conventional compromise) can decrypt the entire archive. For journalists communicating with sources under long-term RSA PGP keys, lawyers holding encrypted client correspondence, or diplomats using legacy encrypted email systems, this is not a theoretical concern.

The asymmetry is worth stating plainly. For personal use of Signal or WhatsApp, the quantum risk is low: forward secrecy substantially mitigates retroactive decryption. For encrypted email with long-term RSA key pairs and long-lived sensitive archives, the HNDL risk is genuine and the exposure begins accumulating now, before any CRQC exists.

Which Applications Are Already Responding

The post-quantum upgrade cycle has started. Two major consumer E2EE applications have already shipped production-ready post-quantum key exchange.

Signal published PQXDH (Post-Quantum Extended Diffie-Hellman) in September 2023. The protocol extends Signal's X3DH key agreement to include ML-KEM-1024, the post-quantum key encapsulation mechanism standardised as FIPS 203, alongside the existing Curve25519 ECDH. The shared secret for each session is derived from both mechanisms: an attacker must break both simultaneously to recover it. PQXDH protects the initial key establishment against HNDL attacks. The Double Ratchet within established sessions uses ephemeral keys that already provided forward secrecy; PQXDH adds a post-quantum layer to the initial keying step that X3DH handles.

Apple updated iMessage to PQ3 cryptography in March 2024. PQ3 combines ML-KEM-768 with Elliptic Curve P-256, providing hybrid classical and post-quantum key encapsulation. Apple classifies PQ3 as providing post-quantum security for both initial key establishment and the ongoing ratcheting mechanism, not just the session initiation.

WhatsApp uses the Signal Protocol and inherits its forward secrecy properties, but had not publicly announced a post-quantum upgrade at the time this article was prepared. Readers should check WhatsApp's current Security Whitepaper and official blog for updated deployment status before drawing conclusions about comparative security. The vendor landscape is moving; publication-date verification is essential for this section.

Proton Mail was piloting post-quantum key support in early 2025, but full PQC migration for all accounts was not complete at that point. For encrypted email specifically, the HNDL exposure on existing RSA-keyed archives remains until those keys are replaced with ML-KEM equivalents. Check Proton's current status directly.

What NIST's Standards Mean for E2EE Developers

NIST finalised four post-quantum cryptography standards between August and October 2024: FIPS 203, 204, and 205 in August; FIPS 206 in October. For E2EE specifically, the most relevant is ML-KEM (FIPS 203), Module-Lattice-Based Key Encapsulation Mechanism, which replaces ECDH for key exchange. It is based on the Module Learning With Errors hardness problem, for which no efficient quantum or classical attack is known.

Signal's PQXDH and Apple's PQ3 both deploy ML-KEM in production. These are not research prototypes, they are serving hundreds of millions of users. The algorithm works at consumer scale.

NIST IR 8547 (November 2024) makes the migration timeline explicit: ECDH, including Curve25519, is designated for deprecation in new deployments from 2030. Developers building new E2EE applications today should design around ML-KEM from the outset rather than planning a subsequent migration. Developers maintaining existing applications should have ML-KEM integration on their roadmap within the IR 8547 window.

For enterprise group messaging, the Messaging Layer Security protocol (RFC 9420) is the standard being extended to support hybrid PQC key exchange. Microsoft Teams and Cisco Webex have stated MLS adoption roadmaps; PQC extensions to MLS will be the migration path for corporate E2EE at scale, and the IETF working group is actively developing them.

For the PKI context, certificate chains, code signing, and the trust infrastructure that underpins E2EE at the ecosystem level, see the PKI and quantum computing explainer. The certificate infrastructure that validates public keys in E2EE systems is a separate migration problem with its own timeline. For the algorithm deprecation schedule governing when ECDH and RSA must be replaced across all new deployments, see the NIST IR 8547 transition timeline.

What This Means in Practice, by Audience

If you are a security professional or developer, the first step is characterising your key architecture. Long-term key pairs (PGP-style) have higher HNDL urgency than ephemeral-key systems with forward secrecy. For new E2EE implementations, Signal's PQXDH specification is a published, production-validated reference for hybrid ML-KEM plus classical key exchange in a messaging context. The Open Quantum Safe project's liboqs library provides tested ML-KEM implementations for direct integration; BouncyCastle offers ML-KEM support for Java and .NET environments.

If you are an IT manager selecting or auditing E2EE tools, the practical question is whether your vendor has a documented PQC roadmap and whether they have shipped against it. Signal and Apple iMessage have shipped. For enterprise messaging, ask your vendor where MLS PQC extensions appear on their roadmap. For encrypted email, treat any deployment still using long-term RSA PGP keys for sensitive long-lived communications as a documented risk that needs a migration plan.

The core misconception to avoid: quantum computers will not be able to mass-decrypt your archived Signal messages. Forward secrecy means there are no stored session keys to recover. A CRQC creates a targeted key exchange problem, not a wholesale message archive decryption capability. The threat is real, specific, and addressable, it is not the apocalyptic blanket exposure that some headlines suggest.