Which Messengers Are Already Quantum-Safe?

Abstract

Key Points at a Glance

1. Why Key Exchange — Not Message Encryption — Is the Quantum Weak Point

Think of a messaging session as two parts: a vault and the locksmith visit that sets its combination. The vault is the symmetric layer — usually a high-strength symmetric cipher that encrypts your message content. The locksmith visit is the key exchange — the cryptographic handshake that establishes the shared secret before a single byte of message is sent. A cryptographically relevant quantum computer primarily threatens the public-key handshake, not modern high-security symmetric encryption such as AES-256.

Shor's algorithm, running on a sufficiently large quantum computer, can derive a private key from a public key in polynomial time. This directly collapses every asymmetric algorithm used in key exchange today: X25519 (Curve25519 ECDH), ECDH over other curves, and RSA. The moment a cryptographically relevant quantum computer (CRQC) exists, any session key negotiated with these primitives can be reconstructed after the fact.

AES-256 is a different story. Grover's algorithm provides a quadratic speedup against exhaustive key search, reducing the effective security of AES-256 to roughly 128-bit quantum security. That remains a conservative symmetric-security target for long-term protection.

Modern messengers like Signal use ratcheting protocols that generate fresh key material as a conversation progresses, providing forward secrecy: compromise of today's state should not expose the full past conversation. In the post-quantum setting, however, a classical elliptic-curve Diffie-Hellman ratchet is not enough by itself. If a ratchet step relies only on classical Diffie-Hellman and the relevant public transcript was harvested, a future quantum adversary could reconstruct that Diffie-Hellman contribution. Protocol state deletion and symmetric chaining still matter, but the classical Diffie-Hellman part no longer provides post-quantum protection.

2. The Harvest-Now, Decrypt-Later Risk for Messaging

As we detail in our analysis of harvest-now, decrypt-later (HNDL) threats, sophisticated adversaries are already intercepting and storing encrypted traffic today, banking on their ability to decrypt it once quantum hardware matures. The question is not whether this is happening — signals intelligence agencies have the infrastructure and the motive — but whether the data collected today is worth decrypting in five to fifteen years.^[6]

For messaging, this risk is distinctly higher than for most TLS web traffic. A typical HTTPS session fetches a web page that loses its value in minutes. A message thread, by contrast, can contain negotiation records, legal discussions, source relationships, and strategic plans that remain sensitive for decades. The "harvest window" for a journalist protecting a source, or a company discussing an acquisition, extends years into the future — well within the projected timeline for early CRQC capability.

Risk calibration matters here. For everyday personal conversations, the probability that a nation-state adversary is storing your traffic and waiting to decrypt it is vanishingly small. But for users operating in high-stakes environments, the threat is real and active today, with no warning before exploitation occurs.

3. What "Quantum-Safe Messaging" Actually Means

A hybrid key encapsulation mechanism (KEM) combines a classical key exchange such as X25519 with a post-quantum KEM such as ML-KEM in a single handshake. In a correctly designed hybrid key exchange, confidentiality is intended to remain secure if either the classical component or the post-quantum component remains secure. This depends on the combiner, authentication binding, downgrade resistance, key separation, and implementation details. Hybrid deployment adds PQ protection without betting everything on an algorithm family whose final NIST standard was published only in 2024.

ML-KEM is the standardized form of CRYSTALS-Kyber, a lattice-based key-encapsulation mechanism standardized in NIST FIPS 203 in August 2024.^[5] It comes in three parameter sets: ML-KEM-512 (NIST Security Level 1), ML-KEM-768 (Level 3), and ML-KEM-1024 (Level 5). Levels 3 and 5 are commonly discussed for messaging deployments — the difference is a trade-off between key/ciphertext size and the security margin against future cryptanalytic improvements.

Forward secrecy in the post-quantum context adds a second dimension beyond just upgrading the initial key exchange. PQXDH protects the session-establishment handshake with ML-KEM. Apple PQ3 goes further by adding periodic post-quantum rekeying inside active sessions. Signal later announced SPQR, a sparse post-quantum ratchet mixed with the existing Double Ratchet as a Triple Ratchet, to add ongoing post-quantum key updates after session establishment.

4. Messenger-by-Messenger Quantum-Safety Analysis

Signal

Signal was the first major consumer messenger to publish and deploy post-quantum session establishment. In September 2023, the Signal Foundation published the PQXDH (Post-Quantum Extended Diffie-Hellman) specification and shipped it to production.^[1] PQXDH replaces the classical X3DH (Extended Triple Diffie-Hellman) session-establishment step with a hybrid construction: an ML-KEM-1024 key encapsulation is layered alongside the existing X25519 Diffie-Hellman, with the shared secrets combined through a key-derivation function. This uses the highest ML-KEM parameter set.

Signal later announced SPQR (Sparse Post Quantum Ratchet), mixed with the existing Double Ratchet as a Triple Ratchet.^[11] This is an important update: Signal should no longer be described only as "post-quantum at session establishment" if the article is being reviewed in 2026. The public claim is that conversations can receive ongoing post-quantum key updates after the initial PQXDH handshake.

Signal is fully open-source, including the libsignal library that implements these protocol components. Its public specifications make Signal one of the most transparent large-scale deployments of post-quantum secure messaging.

Apple iMessage

Apple launched PQ3 in February 2024, shipping with iOS 17.4, iPadOS 17.4, macOS 14.4, and watchOS 10.4.^[2] PQ3 uses ML-KEM-768 combined with Curve25519 (the Edwards form of X25519) for session establishment. Apple's internal security taxonomy runs from Level 1 (no E2EE) to Level 3 (PQ at session start plus in-session rekeying); PQ3 is Level 3 — the highest.

The periodic rekeying is PQ3's defining feature relative to PQXDH. Roughly every 50 messages or 7 days (whichever comes first), iMessage performs a fresh post-quantum key exchange within the ongoing conversation. A HNDL adversary who captures weeks of ciphertext and later obtains a session key can only decrypt messages within the affected rekeying window, not the entire conversation history.

An important scope note: PQ3 protects iMessage — the protocol behind blue-bubble conversations between Apple devices. SMS fallback (green bubbles) and RCS are separate protocols and are not covered. Only device-to-device iMessage with E2EE active receives PQ3 protection.

WhatsApp

WhatsApp is built on Signal Protocol concepts and provides end-to-end encryption for personal messages by default. Public discussion often groups WhatsApp with Signal-style post-quantum messaging upgrades, but no primary WhatsApp or Meta technical source currently documents the exact post-quantum parameters deployed for chat-session key exchange. The only available Meta Engineering source concerns post-quantum security for encrypted backups — a different protocol surface from production chat-session establishment.

Until a technical disclosure clarifies WhatsApp's chat-session key exchange, its post-quantum status remains unconfirmed. The distinction matters: encrypted backups, session establishment, and in-session ratcheting are different protocol surfaces.

WhatsApp is closed-source. Even where high-level protocol claims are published, independent verification of production deployment details is more limited than for open-source implementations such as Signal.

Google Messages

Google Messages provides end-to-end encrypted RCS (Rich Communication Services) conversations when the required client and service conditions are met.^[4] However, no primary Google technical source has confirmed production deployment of post-quantum key exchange (such as ML-KEM-768) for RCS chat sessions.

The standards direction is clear: MLS and post-quantum MLS work are important for future group and cross-platform messaging security. But end-to-end encrypted RCS and post-quantum key exchange are separate capabilities. Standard SMS is not end-to-end encrypted, and cross-platform RCS support depends on the deployed protocol and client stack.

Telegram

Threema

Threema uses NaCl/libsodium for its cryptographic primitives, with X25519 for key exchange. The classical security posture is strong — Threema has undergone independent third-party audits and does not require accounts to be linked to phone numbers or email addresses. In February 2026, Threema announced a collaboration with IBM Research to implement post-quantum cryptography.^[12] This is a public roadmap signal, but not the same as confirmed production PQ deployment.

Viber

Viber adopted end-to-end encryption in 2016 using a custom protocol based on similar double-ratchet concepts to Signal rather than the Signal Protocol implementation itself. The underlying key exchange relies on classical elliptic-curve cryptography. No public post-quantum deployment or roadmap has been disclosed. The classical protocol provides strong security today but is vulnerable to a future CRQC if harvested session-establishment material is sufficient to reconstruct the relevant key exchange.

Wire

Wire has upgraded its standard messaging protocol from Proteus to Messaging Layer Security (MLS).^[10] MLS is a modern standard for end-to-end encrypted group messaging, but a standard MLS deployment is not post-quantum-safe unless it uses a post-quantum MLS ciphersuite or hybrid ML-KEM integration. As of July 2026, no public evidence indicates that Wire's production messaging uses post-quantum key exchange.

Matrix / Element

Matrix is an open, federated messaging protocol; Element is the primary client. The encryption layer uses Olm (a Signal Protocol double-ratchet implementation) and MegOlm for group messaging. The Matrix.org foundation has published research on post-quantum integration — including PQ-MLS approaches — but nothing has reached production as of early 2026.

Matrix's federated and multi-client architecture adds a genuine complexity layer: clients, room versions, device management, cross-signing, key backup, and key-distribution behavior must interoperate across homeservers. This is more complex than a centralized messenger rollout, even though end-to-end encryption is primarily a client-side security property.

5. Head-to-Head: Quantum-Safety Status at a Glance

6. Developer Takeaways: Building or Selecting a Quantum-Safe Messenger

If you are building a new messaging application and need post-quantum key exchange today, do not write ML-KEM from scratch. libsignal, Signal Foundation's open-source library, includes PQXDH and related messaging protocol components. liboqs (Open Quantum Safe project) provides standalone ML-KEM implementations in C with language bindings for Python, Go, Java, and others. The correct engineering task is protocol integration, authentication, downgrade resistance, key storage, and deployment safety — not implementing lattice cryptography by hand.

Key exchange is not the only surface to audit. The key distribution server — the mechanism by which pre-keys are uploaded, stored, and fetched to initiate new sessions — must also be hardened. If an attacker can intercept or replace a pre-key bundle before a session begins, they can substitute a classical-only key regardless of what your protocol specifies. Identity key management (how long-term identity keys are generated, stored, and rotated) is a second vector that PQ-capable protocols must address.

Use the hybrid model during the transition period. Deploying ML-KEM alone, without a classical component, discards the classical security guarantee that users already rely on. Hybrid (PQ + classical) is the correct default until ML-KEM accumulates the same decades of real-world cryptanalytic scrutiny that X25519 has.

Developer checklist:

• Audit your key exchange primitive — replace X25519/ECDH-only with hybrid ML-KEM + X25519
• Use hybrid (PQ + classical), not PQ-only, during the transition period
• Implement periodic rekeying, not just PQ protection at session establishment
• Prefer open-source, audited protocol implementations (libsignal, liboqs)
• Follow NIST FIPS 203 (ML-KEM) as the primary reference standard
• Audit pre-key distribution and identity key management — not just the in-session KEM

7. End-User Guidance: Choosing a Quantum-Safe Messenger

For everyday personal communication — catching up with friends and family, making plans, sharing photos — any end-to-end encrypted messenger provides adequate security today. The quantum computer capable of retroactively breaking past messages does not yet exist, and when it does exist, it will initially be an extraordinarily expensive and scarce resource. Nation-states will not use it to read your dinner plans.

For users with a higher threat model — journalists protecting sources, lawyers discussing privileged matters, executives handling sensitive negotiations — the calculus is different. Prefer messengers with publicly documented post-quantum protections, especially Signal and iMessage. Both are widely available, user-friendly, and have published technical material describing post-quantum messaging protection. Avoid using Telegram cloud chats for sensitive communications regardless of the quantum threat: Telegram's ordinary and group chats are not end-to-end encrypted against Telegram's servers, which is a more immediate and concrete limitation than the future quantum risk.

8. What Comes Next: The PQ Messaging Roadmap

The Messaging Layer Security (MLS) protocol — standardized as IETF RFC 9420 in July 2023 — is the next-generation architecture for group messaging at scale.^[9] MLS defines a tree-based ratcheting scheme that scales end-to-end encryption to large groups efficiently. Post-quantum MLS work is underway in the IETF ecosystem, but implementers should distinguish standards work, draft cipher suites, and production deployment. A messenger should not be called quantum-safe merely because its future architecture may use MLS.

Regulatory pressure on messenger providers will increase. The NSA CNSA 2.0 suite mandates post-quantum algorithm adoption for high-value government and defense communications, with migration timelines beginning in 2025 and targeting completion by 2030.^[13] While consumer messenger regulation has not yet followed, NIS2 (EU) and emerging national cybersecurity frameworks are expected to extend PQ requirements to commercial communications providers handling sensitive or regulated data. Messengers that have not begun PQ migration by 2027–2028 may face compliance pressure in regulated sectors.

Next Step

Understand why messages sent on non-PQ messengers today are a live interception target — even before any quantum computer exists.

How to Cite This Article

@misc{pqcryptography_pqc_messengers,
  author       = {{PostQuantumSecurity.org}},
  title        = {Which Messengers Are Already Quantum-Safe? Signal, WhatsApp, iMessage and More},
  year         = {2026},
  month        = feb,
  day          = {1},
  url          = {https://www.postquantumsecurity.org/publications/pqc_messengers.html}
}

References

1. Signal Foundation. (2023, September). PQXDH: Post-Quantum Extended Diffie-Hellman. https://signal.org/docs/specifications/pqxdh/
2. Apple Security Engineering and Architecture. (2024, February). iMessage with PQ3: The new state of the art in quantum-secure messaging. https://security.apple.com/blog/imessage-pq3/
3. Meta Engineering. (2024). Post-quantum security for end-to-end encrypted backups. Meta Engineering Blog. Note: this source concerns encrypted backups; it should not be used alone to prove WhatsApp chat-session PQXDH deployment.
4. Google Messages Help. About end-to-end encryption in Google Messages. https://support.google.com/messages/answer/10262381
5. National Institute of Standards and Technology. (2024, August). FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM). https://csrc.nist.gov/pubs/fips/203/final
6. PostQuantumSecurity.org. (2025, June). The Quantum Clock Is Ticking: What is Harvest-Now, Decrypt-Later? https://www.postquantumsecurity.org/publications/harvest-now-decrypt-later.html
7. Marlinspike, M., & Perrin, T. (2016, November). The Double Ratchet Algorithm. Signal Foundation. https://signal.org/docs/specifications/doubleratchet/
8. Telegram. MTProto Mobile Protocol. https://core.telegram.org/mtproto
9. Barnes, R., et al. (2023, July). RFC 9420: The Messaging Layer Security (MLS) Protocol. IETF. https://www.rfc-editor.org/rfc/rfc9420
10. Wire. Messaging Layer Security (MLS). https://support.wire.com/hc/en-us/articles/12434725011485-Messaging-Layer-Security-MLS
11. Signal Foundation. (2025, October). SPQR: A Sparse Post-Quantum Ratchet for Signal. https://signal.org/blog/spqr/
12. Threema. (2026, February). Towards a Quantum-Secure Future: Threema and IBM Research Join Forces. https://threema.ch/en/blog/quantum-secure-future
13. National Security Agency. (2022, September). Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) Advisory. NSA/CISA Advisory