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

Most people who use Signal, WhatsApp, or HTTPS have some working assumption that end-to-end encryption means nobody in the middle can read what they are sending. That assumption is broadly correct today. What is less well understood, including among technically sophisticated engineers, is exactly which part of that protection breaks when a cryptographically relevant quantum computer arrives and which part does not.

The answer is precise and the distinction matters. End-to-end encryption, or E2EE, is not one cryptographic mechanism. It is two, working together: an asymmetric key exchange that establishes a shared secret, and a symmetric cipher that encrypts the actual content using that secret. These two layers face entirely different quantum threats. One of them is in trouble. The other, if implemented correctly, is not.

How E2EE Actually Works

The two-layer structure is worth understanding clearly because the quantum risk analysis follows directly from it.

The asymmetric layer is how two parties establish a shared secret without revealing it to anyone watching the network. The most common implementation in current protocols is X25519, an elliptic curve Diffie-Hellman scheme defined in RFC 7748. X25519 uses Curve25519 to perform an ECDH operation: each party generates an ephemeral key pair, exchanges public keys, and independently computes the same shared secret. No observer with access to the network traffic can derive the shared secret without solving the elliptic curve discrete logarithm problem. On a classical computer, that problem is computationally intractable at the key sizes in use. On a sufficiently capable quantum computer, it is not.

The symmetric layer uses that shared secret as the key for encrypting the actual message content. TLS 1.3 (IETF RFC 8446) uses AES-256-GCM for this purpose, an authenticated encryption scheme that provides both confidentiality and integrity protection. AES-256-GCM is not an asymmetric scheme. It does not depend on the hardness of factoring integers or solving discrete logarithms. Its quantum vulnerability profile is therefore fundamentally different from the key exchange layer above it.

Signal, WhatsApp, and Matrix: Where the Quantum Exposure Sits

Signal Protocol, used natively in Signal and WhatsApp, adds a second layer of sophistication through two mechanisms: X3DH and the Double Ratchet Algorithm.

X3DH, the Extended Triple Diffie-Hellman key agreement published by Moxie Marlinspike and Trevor Perrin in November 2016, is Signal's asynchronous session establishment protocol. It combines multiple X25519 operations, using long-term identity keys, signed pre-keys, and one-time pre-keys to establish an initial shared secret. X3DH provides forward secrecy and cryptographic deniability. Every single key exchange in X3DH uses X25519. Shor's algorithm, running on a CRQC, breaks X25519. This is the quantum vulnerability in Signal Protocol.

The Double Ratchet Algorithm, which operates after session establishment, generates a new symmetric key for every message through a combination of Diffie-Hellman ratcheting and symmetric key derivation. The symmetric layer uses AES-256 with HMAC-SHA256. This layer is relatively safe against Grover's algorithm at 256-bit key lengths. But the Double Ratchet only generates session security for messages after the initial X3DH exchange. If an adversary can break the X3DH key establishment, they can derive the session root key and follow the ratchet forward. The ratchet's forward secrecy protects against future compromise of a specific ratchet state. It does not protect against retroactive breaking of the initial X3DH key exchange itself.

WhatsApp implements Signal Protocol natively, including X3DH and the Double Ratchet. Its quantum vulnerability profile is identical to Signal's. Matrix's Olm protocol follows the same structural pattern: Curve25519 key agreement for session establishment, AES-256 symmetric encryption for content. The Curve25519 key agreement stage is the quantum-vulnerable component.

What Shor's Algorithm Breaks

Peter Shor published his algorithm in 1994, in the Proceedings of the 35th Annual Symposium on Foundations of Computer Science. A detailed breakdown of how Shor's algorithm breaks RSA and ECC covers the mechanics for those who want the full technical picture. It solves two computational problems in polynomial time on a quantum computer: integer factorisation, which is the hardness assumption underlying RSA, and the discrete logarithm problem on elliptic curves, which is the hardness assumption underlying ECDH including X25519 and P-256.

On a classical computer, recovering a private X25519 key from the corresponding public key is computationally infeasible. On a CRQC, it becomes tractable. The same applies to RSA certificate authentication and ECDSA certificate signatures. Every certificate in the PKI chain authenticating a TLS 1.3 session relies on RSA or ECDSA signatures. Both break under Shor's algorithm.

For HNDL, Harvest Now, Decrypt Later, attacks, the consequence is direct. An adversary recording TLS 1.3 sessions or Signal Protocol traffic today captures the ECDH public values exchanged during session establishment. Post-CRQC, they recover the session keys by solving those ECDH operations with Shor's algorithm, then decrypt all stored sessions. The ephemeral nature of TLS 1.3's key exchange does not help here. Forward secrecy protects against future compromise of a long-term server private key. It does not protect against retroactive breaking of the ephemeral key exchange operations themselves. HNDL works against forward-secret protocols if those protocols rely on ECDH.

What Grover's Algorithm Does Not Break

Grover's algorithm, published by Lov Grover in 1996, provides a quadratic speedup for unstructured search. Applied to symmetric key brute-force, this means the effective security of a symmetric cipher is reduced by half in bit-length terms: a 256-bit key provides approximately 128-bit effective security under Grover's algorithm, and a 128-bit key provides approximately 64-bit effective security.

The practical implications are specific. AES-256-GCM, the session cipher in TLS 1.3 and Signal Protocol, provides approximately 128-bit effective security under Grover's algorithm. NIST classifies 128-bit symmetric security as equivalent to NIST Security Level 1. At any foreseeable scale of quantum hardware, 2^128 quantum operations to break an AES-256-GCM session is computationally infeasible. AES-256-GCM does not need to be replaced for the foreseeable quantum threat horizon.

AES-128-GCM is a different matter. Its effective security under Grover's algorithm falls to approximately 64-bit, which is not the same level of assurance. Systems currently using AES-128 should prioritise upgrading to AES-256 as part of their quantum migration, even before addressing the asymmetric key exchange layer.

The practical summary: the content encryption layer of E2EE is relatively safe if it uses AES-256. The key exchange layer is not safe in its current form. The urgent migration target is the asymmetric component, not the symmetric one.

Signal's PQXDH: What the Fix Looks Like in Production

The post-quantum upgrade path for E2EE is not theoretical. Signal has deployed it.

In September 2023, the Signal Foundation published PQXDH: Post-Quantum Extended Diffie-Hellman. PQXDH replaces the classical X3DH key agreement with a hybrid scheme that combines X25519 with ML-KEM-1024 (NIST FIPS 203, August 2024, the standardised designation for what was previously called Kyber-1024). The shared secret is derived from both the classical X25519 output and the ML-KEM-1024 encapsulation output, combined through a key derivation function. Signal began deploying PQXDH for new conversations in its client applications in late 2023.

The hybrid construction is the standard-recommended transition architecture. It provides security against a CRQC breaking the X25519 component via Shor's algorithm, because the attacker must also break ML-KEM-1024, whose hardness assumption is Module Learning With Errors. MLWE does not yield to Shor's algorithm. The hybrid also provides security against a classical attack finding a flaw in ML-KEM's implementation, because breaking the session would still require breaking the classical X25519 component as well. During the transition period, the hybrid is strictly safer than either scheme alone.

ML-KEM-1024 provides NIST Security Level 5, equivalent to AES-256 symmetric security. For E2EE applications requiring strong post-quantum guarantees, ML-KEM-1024 is the appropriate parameter set. ML-KEM-768, at Security Level 3, is equivalent to AES-192 and is the commonly recommended default for general deployment where performance constraints exist.

The Transition Status for Other E2EE Contexts

TLS 1.3 is moving towards hybrid post-quantum key exchange through a combination of standards work and browser deployment. Google and Cloudflare have deployed hybrid schemes including X25519Kyber768Draft00 in Chrome and on their infrastructure. This is an IETF draft, not yet a ratified standard, but it demonstrates the deployment trajectory. The IETF is working to ratify hybrid key exchange for TLS 1.3 as a standards-track specification.

WhatsApp has not published a PQXDH deployment timeline as of May 2026. For context on how state actors are already targeting E2EE traffic through HNDL collection, see the state actor HNDL campaigns analysis. For historically captured WhatsApp traffic, HNDL applies to sessions established before any PQXDH deployment. Matrix's Olm protocol does not yet have a published post-quantum migration timeline.

For organisations and developers choosing E2EE applications and protocols, the preference should be towards implementations that have committed to or completed post-quantum key agreement upgrades. Signal's deployment of PQXDH for new conversations is a concrete and verifiable example. Conversations established before PQXDH deployment retain the historical exposure of X3DH.

The Active Risk Dimension: HNDL and Stored Traffic

The Global Risk Institute's 2024 survey of 37 quantum computing and security experts estimated a 14-34% probability of a CRQC capable of breaking RSA-2048 existing by 2033-2035. That probability range frames the timeline for when the key exchange layer becomes exploitable. HNDL frames the risk for data captured now.

For HTTPS traffic to web applications handling long-lived sensitive data, financial records, legal communications, health information, the HNDL window is open now. An adversary recording those sessions today faces a future decryption task with a 14-34% probability of becoming executable within a decade. For data with a sensitivity horizon that extends beyond 2033, HNDL is a present operational concern rather than a future planning item.

To assess when your organisation's data lifetime exposure creates a quantum risk window, QSECDEF's Q-Day timeline risk calculator provides a structured framework. For further context on the HNDL threat model applied to specific data types, the data-at-risk guide covers prioritisation methodology. The post-quantum TLS explainer covers the migration specifics for the web traffic layer.

The Summary Position

E2EE is broken in one layer and intact in another, and the distinction is precise enough to be actionable. The key exchange layer, specifically the ECDH operations in X3DH, TLS 1.3, and every protocol using X25519 or P-256, is vulnerable to Shor's algorithm on a future CRQC. The content encryption layer, specifically AES-256-GCM, survives Grover's algorithm with approximately 128-bit effective security and does not require replacement.

The fix for the key exchange layer is available and in production. Signal's PQXDH shows what hybrid post-quantum key agreement looks like at scale. The question for every E2EE application and protocol is not whether the fix exists. It is whether it has been deployed, and when historical exposure for previously captured traffic begins to matter.