Apple PQ3 Explained

Published

Apple shipped PQ3, its post-quantum cryptographic protocol for iMessage, with iOS 17.4, iPadOS 17.4, macOS 14.4, and watchOS 10.4 in February 2024. It is not experimental. It is not a flag you need to enable. Every iMessage conversation between devices running these versions or later automatically uses PQ3 encryption.

This makes iMessage the first widely deployed messaging app to reach what Apple calls “Level 3” post-quantum security, meaning post-quantum cryptography protects both the initial key exchange and the ongoing message ratchet. Signal’s PQXDH protocol, introduced in late 2023, reaches Level 2 by applying post-quantum cryptography only to the initial key establishment.

This article explains how PQ3 works technically, what it protects against, and what remains outside its scope.

The threat model: Harvest Now, Decrypt Later

PQ3 is designed primarily to defeat Harvest Now, Decrypt Later (HNDL) attacks. An adversary with large storage capacity can record encrypted iMessage traffic today. If a sufficiently powerful quantum computer becomes available in the future, they could retroactively break the classical key exchange and decrypt those stored conversations.

By combining a post-quantum key encapsulation mechanism (KEM) with classical elliptic curve cryptography, PQ3 ensures that even a future quantum computer cannot decrypt messages unless it can also break the post-quantum algorithm. This is the hybrid security guarantee: an attacker must defeat both algorithms simultaneously.

Security levels for messaging protocols

Apple defines a four-level classification:

  • Level 0: No end-to-end encryption by default (SMS, basic chat apps)
  • Level 1: End-to-end encryption with classical cryptography only (most E2EE apps including WhatsApp, pre-PQXDH Signal)
  • Level 2: Post-quantum protection in initial key establishment only (Signal with PQXDH)
  • Level 3: Post-quantum protection in both initial key establishment and ongoing rekeying (iMessage with PQ3)

The distinction between Level 2 and Level 3 matters because if an attacker compromises a session key at any point, Level 2 provides no post-quantum recovery mechanism. PQ3 does, through its post-quantum rekeying ratchet.

How PQ3 key establishment works

Each iMessage device generates and registers two public encryption keys with Apple’s Identity Directory Service (IDS):

  1. A Kyber-1024 key encapsulation public key (post-quantum)
  2. A P-256 elliptic curve key agreement public key (classical)

These keys are signed with ECDSA using the device’s P-256 authentication key, which is generated and protected by the Secure Enclave. The authentication key is itself signed by the Contact Key Verification account key.

When Alice wants to message Bob, her device retrieves Bob’s key bundle from IDS and performs two operations:

  1. An ECDH key exchange combining Alice’s ephemeral P-256 key with Bob’s registered P-256 public key, producing a classical shared secret
  2. A Kyber-1024 key encapsulation using Bob’s registered Kyber-1024 public key, producing a post-quantum shared secret

These two secrets are combined using HKDF-SHA384-Extract (invoked twice, once per secret), then combined again with session metadata (user identifiers, public keys, encapsulated secret) via a third HKDF-SHA384-Extract invocation. The result is the initial session keying state.

The critical property: recovering this initial state requires breaking both P-256 ECDH and Kyber-1024. Neither alone is sufficient.

The triple ratchet design

PQ3 uses three ratchets working together to provide forward secrecy and post-compromise security:

Ratchet 1: Symmetric ratchet (per-message)

For every message, a per-message encryption key is derived from the current session key using HKDF-SHA384. The session key is then ratcheted forward. The per-message key is deleted after use. This provides classical forward secrecy: compromising the device state at time T does not reveal keys for messages before T.

This ratchet uses 256-bit keys and intermediate values with HKDF-SHA384 as the derivation function, providing 128-bit security against quantum attacks on symmetric primitives.

Ratchet 2: ECDH ratchet (per-response)

A fresh P-256 ECDH public key is transmitted with every response message. The sender’s new private key and the recipient’s last public key produce a new shared secret, which is mixed into the session state. This provides classical post-compromise security: after a key compromise, the next ECDH exchange restores confidentiality.

The overhead is only 32 bytes per message (the compressed P-256 point).

Ratchet 3: Post-quantum KEM ratchet (periodic)

This is what makes PQ3 Level 3. Periodically, a fresh Kyber-768 public key and corresponding encapsulated ciphertext are exchanged between devices. (Note: Kyber-768 is used for ratcheting, while Kyber-1024 is used for initial key establishment. This is a deliberate trade-off: ratcheting keys are single-use, limiting the window of compromise, so the somewhat smaller parameter set is acceptable.)

The KEM ratchet adds approximately 2 KB of overhead per occurrence. To manage bandwidth, the ratchet fires approximately every 50 messages, with a hard guarantee of at least once every 7 days. The rekeying condition also accounts for device connectivity.

Completing any public key ratchet requires a round trip. iMessage’s encrypted delivery receipts allow the ECDH and Kyber ratchets to complete even without an explicit reply from the recipient.

Key derivation and combination

All three ratchet outputs feed into a combined derivation chain:

  1. The symmetric ratchet derives a candidate key from the current state
  2. If an ECDH ratchet fires, the ECDH shared secret is mixed in via HKDF-SHA384-Extract
  3. If a Kyber KEM ratchet fires, the KEM shared secret is also mixed in
  4. The final message key is used for AES-CTR-256 encryption with a derived IV

The combination is sequential: each ratchet’s output updates the state independently, and the final message key reflects all available entropy.

Encryption and padding

Messages are padded before encryption using the Padme heuristic (from the 2018 paper by Bossuat et al.). Padme limits information leakage about message length to O(log log M) bits with at most 12% overhead. This is more efficient than simple power-of-two padding while still preventing meaningful length analysis.

The padded payload is encrypted with AES-CTR using a 256-bit key and initialization vector, both derived from the per-message key. The 256-bit key size provides 128-bit post-quantum security for the symmetric encryption.

Authentication

Each message is signed with ECDSA using the P-256 device authentication key stored in the Secure Enclave. The signature covers:

  • User identifiers and push notification tokens
  • The encrypted payload and authenticated data
  • A ratchet-derived message key indicator (binding the signature to a specific position in the ratchet)
  • All public key material used in the protocol

Authentication remains classical (P-256 ECDSA). Apple explicitly states this is intentional: authentication attacks cannot be performed retroactively. An attacker would need a quantum computer at the time the communication takes place to forge a signature. This is a fundamentally different threat from HNDL, which PQ3 is designed to address.

What PQ3 protects

  • Confidentiality against future quantum computers: Both initial key exchange and ongoing messages are protected by hybrid classical + post-quantum key agreement
  • Forward secrecy: The symmetric ratchet ensures past messages cannot be decrypted even with current device compromise
  • Post-compromise security: Both ECDH and Kyber ratchets restore confidentiality after device compromise
  • Harvest Now, Decrypt Later: Stored ciphertext cannot be retroactively decrypted by a future quantum computer

What PQ3 does NOT protect

  • Authentication against quantum attacks: Sender authentication uses classical ECDSA. A quantum attacker present at the time of communication could theoretically forge signatures. Apple considers this acceptable because such attacks require a contemporaneous quantum computer, not future capability.
  • Metadata: iMessage still routes through Apple’s servers. Message timing, sender/recipient identifiers, and frequency remain visible to Apple and potentially to network observers.
  • Device compromise during communication: If an attacker has ongoing access to the device’s Secure Enclave, they can read messages as they arrive. PQ3 protects stored ciphertext and recovers after compromise, but cannot protect against active device compromise.
  • Non-iMessage fallback: SMS/MMS fallback has no encryption. RCS support (added in iOS 18) does not use PQ3.
  • Group conversations: PQ3 protects pair-wise device sessions. Group conversations consist of multiple pair-wise sessions, each individually protected by PQ3.

Formal verification

PQ3 has been formally verified through two independent analyses:

  1. Professor Douglas Stebila (University of Waterloo): Game-based reduction proofs showing PQ3 provides confidentiality as long as either P-256 ECDH remains hard or Kyber KEM remains secure.
  2. Professor David Basin (ETH Zurich): Symbolic verification using the Tamarin prover, producing machine-checked proofs of secrecy and authenticity properties even against quantum adversaries.

Both papers are published on Apple’s security research site and on the IACR ePrint archive.

Deployment timeline

DateMilestone
February 21, 2024PQ3 announced by Apple Security Engineering and Architecture (SEAR)
March 2024iOS 17.4, iPadOS 17.4, macOS 14.4, watchOS 10.4 ship with PQ3
2024PQ3 fully replaces the prior protocol for all supported device pairs
2025Apple adds post-quantum key exchange to Safari (Safari 26, iOS 26) via ML-KEM

PQ3 adoption is automatic. There is no user-facing setting. If both devices in a conversation support PQ3, it is used. Apple’s IDS protocol versioning prevents downgrade attacks.

Comparison with Signal PQXDH

PropertySignal PQXDHiMessage PQ3
Post-quantum initial key exchangeYes (Kyber-1024)Yes (Kyber-1024 + P-256 hybrid)
Post-quantum ongoing ratchetNo (added later with SPQR in June 2025)Yes (Kyber-768 periodic ratchet)
Classical ratchetDouble Ratchet (X25519)Triple ratchet (ECDH P-256 + Kyber-768 + symmetric)
AuthenticationClassical (Ed25519)Classical (P-256 ECDSA via Secure Enclave)
Security levelLevel 2 (Level 3 with SPQR)Level 3
ShippedSeptember 2023March 2024

Note: Signal announced SPQR (Sparse Post-Quantum Ratchet) in June 2025, which adds periodic post-quantum rekeying to the Signal Protocol, bringing it to Level 3 as well.

Implementation considerations

PQ3 runs on consumer hardware including Apple Watch. The Kyber-768 ratchet’s 2 KB overhead is managed by amortizing it over multiple messages. The adaptive rekeying criterion ensures devices with poor connectivity do not experience visible latency increases.

The Secure Enclave hardware enforces key isolation: even if the application processor is fully compromised, the attacker cannot extract the P-256 authentication private key. After device recovery (reboot or software update), the attacker loses signing capability.

References

  • Apple Security Research: “iMessage with PQ3: The new state of the art in quantum-secure messaging at scale” (February 2024)
  • Stebila, D.: “Security analysis of the iMessage PQ3 protocol” (IACR ePrint 2024/357)
  • Basin, D., Linker, F., Sasse, R.: “A Formal Analysis of the iMessage PQ3 Messaging Protocol” (IACR ePrint 2024/1395, USENIX Security 2025)
  • NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)
  • Apple Platform Security Guide: “Quantum-secure cryptography in Apple operating systems”

FAQ

Is PQ3 enabled by default?

Yes. Every iMessage conversation between devices running iOS 17.4 or later uses PQ3 automatically. There is no setting to toggle. The upgrade happens transparently when both devices support the protocol.

Does PQ3 protect against all quantum attacks?

No. PQ3 protects message confidentiality against future quantum computers (Harvest Now, Decrypt Later). It does not provide post-quantum authentication. Sender verification still relies on classical ECDSA signatures. Apple considers this acceptable because authentication attacks require a quantum computer at the time of communication, not in the future.

Why does Apple use Kyber-1024 for initial key exchange but Kyber-768 for ratcheting?

Initial key exchange keys are registered with Apple’s servers and may be used multiple times before refresh. Kyber-1024 provides NIST Level 5 security for these longer-lived keys. Ratcheting keys are ephemeral and single-use, so Kyber-768 (NIST Level 3) offers sufficient security with smaller ciphertext overhead (approximately 2 KB vs. 2.5 KB per ratchet).

How often does the post-quantum ratchet fire?

Approximately every 50 messages, with a hard upper bound of once every 7 days regardless of message count. Apple has stated this frequency can be increased via software updates without breaking backward compatibility.

Does PQ3 work on Apple Watch?

Yes. watchOS 10.4 shipped with PQ3 support. The protocol is designed to be efficient enough for constrained devices.

Is PQ3 open source or standardized?

PQ3 is proprietary to Apple and not an open standard. However, Apple has published detailed protocol specifications and invited independent formal verification. The underlying algorithms (Kyber/ML-KEM, P-256 ECDH, HKDF-SHA384) are all public standards.

What happens if one device in a conversation does not support PQ3?

The conversation falls back to the previous iMessage encryption protocol (ECC-based). Apple’s protocol versioning negotiation handles this gracefully. There is no partial PQ3 mode.

Sources