Quantum-Secure Messaging: Signal Protocol and the Post-Quantum Future

Signal, iMessage, and WhatsApp all made post-quantum announcements between 2023 and 2024. The coverage that followed used phrases like "quantum-safe messaging" and "fully protected" in ways that require unpacking. Each application addressed a specific cryptographic component. None of them addressed everything. Understanding what changed, what remains classically vulnerable, and why the distinction matters requires looking at the actual protocol mechanics rather than the press releases.

For context on why post-quantum protection differs from quantum cryptography altogether, see the difference between post-quantum and quantum cryptography before reading this article. The two are not the same, and the confusion between them distorts how organisations assess their messaging security posture.

Two Separate Problems in Messaging Security

Post-quantum security in messaging has two distinct cryptographic problems. Most implementations have addressed one of them.

The first problem is initial key establishment. When you open a Signal conversation, the app runs an Extended Triple Diffie-Hellman (X3DH) handshake to derive the session key. X3DH uses X25519, an elliptic curve Diffie-Hellman construction. Shor's algorithm on a cryptographically relevant quantum computer (CRQC) breaks X25519 by solving the elliptic curve discrete logarithm problem. Replacing X25519 with ML-KEM (FIPS 203, formerly Kyber) in the handshake addresses this specific vulnerability.

The second problem is ongoing ratchet security. The Double Ratchet algorithm manages encryption for every individual message after session establishment. It derives a fresh key for each message from a chain of computations that includes Diffie-Hellman ratchet steps. Those ratchet steps also use X25519. An adversary who records a full ratchet session and later obtains a CRQC could potentially work backwards through the X25519 ratchet keys if they recover the initial ratchet state. This second problem is harder to solve and requires injecting post-quantum key material into the ratchet itself, not just the initial handshake.

Signal's PQXDH upgrade addressed problem one. Apple's PQ3 attempted to address both. That is the core distinction.

What Signal's PQXDH Actually Changed

Signal deployed PQXDH (Post-Quantum Extended Triple Diffie-Hellman) in September 2023. The construction extends the existing X3DH handshake rather than replacing it.

In the original X3DH protocol, the session key is derived from four Diffie-Hellman operations between combinations of the sender's and recipient's identity, signed prekey, and one-time prekey. PQXDH keeps those four classical operations intact and adds a fifth component: a one-time ML-KEM-1024 prekey. The recipient registers this ML-KEM-1024 public key (1,568 bytes) on the Signal server alongside their classical prekey bundle. At session initiation, the sender encapsulates a shared secret under that ML-KEM-1024 key and combines the ML-KEM output with the X25519 output through HKDF to derive the final session key.

Signal chose ML-KEM-1024, the highest security parameter set under FIPS 203 (security category 5, equivalent to AES-256). This is a deliberate choice of maximum security margin. The ML-KEM-1024 encapsulation key is 1,568 bytes, ciphertext 1,568 bytes. Signal engineered its prekey infrastructure to accommodate this without breaking the existing prekey protocol.

The security argument is straightforward: the combined session key is secure unless both X25519 (broken by Shor's algorithm) and ML-KEM-1024 (broken by a currently unknown algorithm) are compromised simultaneously. A CRQC breaks the classical half. Breaking the post-quantum half requires a separate, not-yet-existing attack. The hybrid construction provides a genuine security improvement over X25519-only handshakes.

What PQXDH did not change: the Double Ratchet algorithm. Every message after the initial handshake continues to use X25519-based ratchet steps. The identity keys and signed prekeys remain X25519-format. Post-quantum authentication of sender identity is not part of PQXDH. Signal's own specification acknowledges these limitations and describes them as future work. For a deeper look at how key encapsulation mechanisms work and why they differ from key agreement protocols, see how key encapsulation mechanisms work.

Why the Ratchet Gap Matters Under HNDL

The Harvest Now Decrypt Later (HNDL) threat model is the reason any of this is urgent in 2026. A state-level adversary recording Signal traffic today acquires ciphertext encrypted under X25519. Under classical assumptions, that ciphertext is secure indefinitely. Under HNDL, if the adversary obtains a CRQC before the recorded session keys are no longer relevant, they could decrypt the recorded content.

For most conversational content, the sensitivity window is short. Three to seven years of protection is sufficient for the majority of personal and business communications. Q-Day, the point at which a CRQC capable of breaking RSA-2048 or X25519 is believed likely to exist, falls approximately in the 2033 to 2035 range based on current roadmaps from IBM, Google, and defence agency assessments in NIST IR 8547 (November 2024). Signal PQXDH, which protects the initial session key, provides meaningful HNDL protection for most communication content by ensuring the initial key cannot be reconstructed from a recorded handshake.

The ratchet gap changes the picture for recorded full-session traffic. The Double Ratchet derives per-message keys from ratchet state through HKDF-SHA256. HKDF operates on hash functions, and SHA-256 retains approximately 128 bits of post-quantum security under Grover's algorithm. The forward secrecy property of the ratchet, that old message keys are deleted and cannot be derived backwards from current state, holds under both classical and quantum assumptions because it relies on those hash operations, not on the asymmetric component.

The vulnerability is narrower than it first appears: a CRQC breaking the initial PQXDH-protected session key cannot directly recover the per-message ratchet keys derived from it, because those keys are one-way hash derivatives. The remaining exposure is at the X25519 ratchet steps themselves, where an adversary who records the full ratchet state transitions could use a CRQC against those specific X25519 operations. [INFERRED — the practical exploitability of ratchet-step X25519 exposure under HNDL depends on adversary capability to record and correlate full ratchet state; no published cryptanalysis of PQXDH Double Ratchet hybrid has demonstrated this attack chain.] For most sensitivity windows, this is a secondary risk after the initial handshake. For legally sensitive or government-grade communications with multi-decade sensitivity, it remains an open concern.

Apple PQ3: Addressing the Ratchet

Apple deployed iMessage PQ3 in February 2024, with iOS 17.4 and macOS 14.4. The protocol differs from Signal PQXDH in one critical respect: it injects ML-KEM key establishment into the conversation periodically, not just at session start. Apple chose ML-KEM-768 (security category 3, not category 5) for PQ3, a deliberate decision based on the argument that more frequent re-keying with a smaller parameter set provides better practical security than infrequent re-keying with a larger one.

Apple's own security taxonomy characterises PQ3 as "Level 3" in their messaging security classification:

• Level 0: no end-to-end encryption (SMS)
• Level 1: classical end-to-end encryption
• Level 2: post-quantum protection at initial session establishment only (Signal PQXDH)
• Level 3: post-quantum protection throughout the conversation (PQ3)

This taxonomy is Apple's own and should be read as such. It is analytically useful as a framework, but "Level 3" is not an independent standard, it is Apple's characterisation of their own system. The distinction Apple draws is genuine: post-quantum protection at initial handshake and post-quantum protection throughout the ratchet are different threat mitigations.

The PQ3 re-keying mechanism means a CRQC adversary harvesting iMessage traffic must break a fresh ML-KEM-768 key for each re-keying period rather than just the session establishment key. Apple has not published a specific re-keying interval (number of messages or time period); the public description states it occurs "periodically." A formal security analysis of PQ3 by Apple's security research team, with contributions from external cryptographers, provides a proof of the construction's security properties under the assumption that ML-KEM-768 is secure. The analysis is available as a preprint via IACR ePrint.

The Messaging Landscape: What Has and Has Not Moved

PQC status as at July 2026. Verify current implementation status before relying on this table for security decisions.

Telegram requires a specific note. Its standard chats are not end-to-end encrypted. They are server-encrypted: Telegram's servers hold the keys and can read those messages. Secret Chats use end-to-end encryption under MTProto 2.0 with classical Diffie-Hellman key exchange, which is quantum-vulnerable. As of Q2 2026, Telegram had not announced any post-quantum migration for MTProto. This is not a criticism for general use cases; it is material for anyone treating Telegram Secret Chats as equivalent to Signal for sensitive communications.

WhatsApp's 2024 announcement of post-quantum work described ML-KEM integration into its Key Transparency infrastructure, a server-side key vault mechanism. This is distinct from the Signal Protocol session layer that WhatsApp uses for end-to-end encrypted messages. WhatsApp's core message encryption remained on the classical Signal Protocol as of Q1 2026. The two should not be conflated.

Wire deployed a hybrid Kyber + X25519 construction in 2023, prior to FIPS 203 finalisation. [ASSUMED — Wire's current FIPS 203 alignment and Threema's PQC migration status not confirmed; verify current implementation documentation before relying on this table for security decisions.] Kyber (the pre-standardisation name for ML-KEM) and the final FIPS 203 standard differ in encoding and domain separation parameters. Implementations using Kyber Round 3 are not directly interoperable with FIPS 203 compliant systems and should be verified for alignment before being treated as ML-KEM-compliant.

Four Misconceptions Worth Correcting

Signal is now quantum-safe. Signal PQXDH protects the initial session key establishment. The Double Ratchet that generates per-message keys still uses X25519. The upgrade is a meaningful improvement, not a complete migration.

Apple chose a weaker algorithm than Signal. Apple chose ML-KEM-768 against Signal's ML-KEM-1024. This was not a security shortcut. Apple's argument is that frequent re-keying with ML-KEM-768 bounds the adversary's exposure window in a way that a stronger but less frequent key agreement does not. The comparison between the two approaches is an architectural choice, not a capability gap.

ML-KEM protects against authentication forgery. ML-KEM is a key encapsulation mechanism. It protects the confidentiality of the session key. Post-quantum authentication, protection against an adversary forging sender identity with a CRQC, requires a signature algorithm: ML-DSA (FIPS 204) or SLH-DSA (FIPS 205). Neither Signal PQXDH nor Apple PQ3 has migrated identity authentication to a post-quantum signature scheme. This is a separate, second-order concern for HNDL scenarios but is relevant if an adversary can break Ed25519 or X25519 authentication in real time.

These upgrades are irrelevant until quantum computers exist. HNDL attacks record ciphertext now and decrypt later. An adversary storing Signal or iMessage traffic in 2026 is acting now, not waiting. The protection value of PQXDH and PQ3 applies to any content with a sensitivity window reaching into the 2033 to 2035 period.

What to Assess for Your Own Communications

The Signal and iMessage upgrades are important. They are also only the messaging application layer. Enterprise communications infrastructure, VPN traffic, and TLS connections carry their own cryptographic exposure. For organisations assessing messaging security as part of a broader PQC programme, the messaging application is a single component, not the whole picture.

The practical questions are: what is the sensitivity window for the communications in scope, who is the realistic adversary, and which layer of the communications stack is the primary exposure? For most organisations, the answer to the last question is not the messaging application layer, it is TLS and key management infrastructure. Messaging application upgrades are a visible signal that the industry is moving. They are not a substitute for a programme-level PQC assessment.