WWDC Quick Look đź’“ By SwiftGGTeam
中文 EN 日本語
Get ahead with quantum-secure cryptography

Get ahead with quantum-secure cryptography

System ServicesPrivacy & Security
Watch original video

Highlight

Quantum computers will break RSA and elliptic-curve public-key algorithms in polynomial time. Attackers are already doing “harvest now, decrypt later.” iOS 26 turns on TLS quantum-secure key exchange by default in URLSession and Network.framework, while CryptoKit ships Post-quantum HPKE, X-Wing, ML-KEM, and ML-DSA.

Core Content

The threat is not science fiction. An attacker can intercept encrypted traffic today, store it on disk, and decrypt it later when a quantum computer becomes available. This “Harvest Now, Decrypt Later” attack works against all sensitive data sent across a network — health records, location data, photos — and it breaks confidentiality. The other class is signature forgery: once quantum computing is available, an attacker can reverse a public signature to recover the private key, then impersonate the user and issue operations to the server. This hits identity-authentication scenarios such as WebAuthn, multi-factor sign-in, and asset signing (03:18).

Apple’s response has two layers. Symmetric encryption is only weakened by a constant factor, so bumping AES-128 up to AES-256 is enough. Public-key encryption must switch algorithms: Apple recommends a “post-quantum hybrid” construction — stack a post-quantum algorithm on top of a classical one, so the attacker has to break both at the same time to succeed (06:32). On the ground, iMessage already switched to the PQ3 protocol in iOS 17.4. iOS 26 turns on quantum-secure TLS by default; CloudKit, APNs, iCloud Private Relay, Safari, Weather, and Maps are all following suit. CryptoKit adds four new APIs — Post-quantum HPKE, X-Wing, ML-KEM, and ML-DSA — backed by the Secure Enclave and formally verified.

Detailed Content

The session’s demo project is a rock-climbing app that end-to-end encrypts the user’s health data, routes, and photos and syncs them across the user’s own devices. TLS is not enough here — TLS only protects the link between the client and the TLS termination point (i.e., the relay server), but the data must stay secret from the server itself (14:14). So the app uses a custom protocol plus Post-quantum HPKE.

let ciphersuite = HPKE.Ciphersuite.XWingMLKEM768X25519_SHA256_AES_GCM_256

// Recipient
let privateKey = try XWingMLKEM768X25519.PrivateKey.generate()
let publicKey = privateKey.publicKey

// Sender
var sender = try HPKE.Sender(recipientKey: publicKey, ciphersuite: ciphersuite, info: info)
let encapsulatedKey = sender.encapsulatedKey

// Recipient
var recipient = try HPKE.Recipient(privateKey: privateKey, ciphersuite: ciphersuite, info: info, encapsulatedKey: encapsulatedKey) 

// Sender encrypts data
let ciphertext = try sender.seal(userData, authenticating: metadata)

// Recipient decrypts message
let decryptedData = try recipient.open(ciphertext, authenticating: metadata)
#expect(userData == decryptedData)

Key points:

  • HPKE.Ciphersuite.XWingMLKEM768X25519_SHA256_AES_GCM_256: picks the X-Wing hybrid KEM (ML-KEM-768 + X25519), derives keys with HKDF-SHA-256, and encrypts with AES-GCM-256; this is the new post-quantum suite added to HPKE in iOS 26.
  • XWingMLKEM768X25519.PrivateKey.generate() and .publicKey: the recipient generates an X-Wing key pair and sends the public key to the sender. Migrating from classical HPKE only changes the ciphersuite and key type — a few lines of code (15:16).
  • HPKE.Sender(recipientKey:ciphersuite:info:): the sender builds a sender object from the recipient’s public key; encapsulatedKey is the encapsulated key that travels with the ciphertext to the peer.
  • HPKE.Recipient(privateKey:ciphersuite:info:encapsulatedKey:): the recipient recovers the session key using its own private key and the encapsulatedKey from the sender.
  • sender.seal(_:authenticating:): encrypts the user data and binds the metadata as AAD to the ciphertext to prevent tampering.
  • recipient.open(_:authenticating:): verifies with the same metadata and decrypts to recover the original data.

Lower-level primitives are also exposed: the X-Wing KEM is available on its own, ML-KEM-768 is exposed as a post-quantum primitive, and on the signing side ML-DSA is provided so you can assemble a post-quantum hybrid signature at the application layer (17:53). Both ML-KEM and ML-DSA support the Secure Enclave, so key operations can be forced to run inside the hardware-isolated environment. The core implementation is formally verified against FIPS 203. On the server side, you can use Swift Crypto to get the same API as CryptoKit, or swap in any library that supports standard post-quantum algorithms (18:26).

The iOS 26 default-on scope is limited to URLSession and Network.framework; the older Secure Transport stack will not receive a post-quantum upgrade, so migrate away from it as soon as possible. If you run your own servers, upgrade the TLS library and configuration yourself. If you use a CDN or managed host, most already support it — just flip a switch (10:53).

Core Takeaways

  1. Audit every “data in transit” point in your protocols: list every place in your app that uses encrypted transport or signatures, and mark whether it uses TLS or a custom HPKE / signature scheme. Hand off to URLSession wherever you can; the iOS 26 upgrade to TLS quantum-secure key exchange is free gains.
  2. Replace classical HPKE with Post-quantum HPKE: if you already use CryptoKit’s HPKE for end-to-end encryption (e.g., IM, device-to-device sync, backup decryption), the migration only touches the ciphersuite and key type. Run the X-Wing suite in a test environment first, then roll out server-side key distribution gradually.
  3. Evaluate ML-DSA for your signing pipeline: long-lived signatures such as user login, device credentials, and asset signing will be retroactively broken once quantum computing is available. Move private keys into the Secure Enclave now, and prepare a migration path to post-quantum hybrid signatures (classical + ML-DSA).
  4. Use Swift Crypto or a standard library on the server: the iOS 26 CryptoKit APIs are fully aligned with Swift Crypto, so a Swift backend can share code directly. For other languages, pick an implementation that meets the FIPS 203 (ML-KEM) / FIPS 204 (ML-DSA) standards; avoid rolling your own.
  5. Drop Secure Transport and custom network stacks: Apple has made it clear that the old APIs will not get a post-quantum upgrade. Replace any remaining Secure Transport calls with URLSession, or rebuild custom stacks on top of Network.framework, and close out that cleanup as a side benefit of this security upgrade.

Comments

GitHub Issues · utterances