CryptoKit Quantum: Protect Your Apps Against Quantum Threats
Published on · 16 min
iOS 26 introduces a silent revolution in CryptoKit: post-quantum cryptography. With the new ML-KEM, ML-DSA and hybrid HPKE APIs, your applications can protect themselves today against attacks from future quantum computers. Let's discover how to implement these protections.
The quantum threat explained
Harvest Now, Decrypt Later
Quantum computers capable of breaking current cryptography don't exist yet. But malicious actors are already applying a formidable strategy: Harvest Now, Decrypt Later (HNDL).
The principle is simple: intercept and store encrypted data today (diplomatic communications, banking transactions, industrial secrets), then wait for the advent of sufficiently powerful quantum computers to decrypt them.
This threat is particularly critical for:
- Medical data (lifetime confidentiality)
- State secrets (decades of relevance)
- Historical financial transactions
- Intellectual property
Why current crypto is vulnerable
Current asymmetric cryptography algorithms (RSA, ECDSA, ECDH) rely on mathematical problems that are difficult for classical computers: factorization of large numbers and discrete logarithm on elliptic curves.
Shor's algorithm, executed on a sufficiently powerful quantum computer, solves these problems in polynomial time — making RSA and ECC completely broken.
“Liquid Glass is a new digital meta-material" was a visual revolution. Post-quantum cryptography is an invisible revolution, but just as fundamental.”
NIST standards
In August 2024, NIST finalized the first post-quantum cryptography standards:
| Standard | Algorithm | Usage |
|---|---|---|
| FIPS 203 | ML-KEM (formerly CRYSTALS-Kyber) | Key encapsulation (encryption) |
| FIPS 204 | ML-DSA (formerly CRYSTALS-Dilithium) | Digital signatures |
| FIPS 205 | SLH-DSA (formerly SPHINCS+) | Signatures (hash-based backup) |
These algorithms use lattice-based cryptography, resistant to known quantum attacks.
Automatic adoption: TLS 1.3 Quantum-Secure
Good news: starting with iOS 26, TLS 1.3 connections automatically negotiate a quantum-secure key exchange if the server supports it.
What changes
The iOS 26 ClientHello now includes X25519MLKEM768 in the supported_groups extension. Compatible servers can select this hybrid algorithm; others continue with classic methods.
Apple services already protected
Apple has deployed quantum-secure TLS on:
- CloudKit
- Push Notifications (APNs)
- Safari
- Maps
- Weather
- iCloud Private Relay
Check server compatibility
On macOS Tahoe 26, test your server:
Post-Quantum HPKE: The high-level API
For end-to-end encryption in your application, use Post-Quantum HPKE (Hybrid Public Key Encryption).
Why HPKE?
HPKE combines:
- Key encapsulation: X-Wing (hybrid X25519 + ML-KEM-768)
- Symmetric encryption: AES-GCM-256
- Key derivation: SHA-256
The hybrid approach guarantees security: even if ML-KEM proves vulnerable, X25519 protects against classical attacks. And vice versa.
Complete example
Error handling
ML-KEM: Low-level key encapsulation
To implement your own cryptographic protocols, CryptoKit directly exposes ML-KEM (Module-Lattice Key Encapsulation Mechanism).
KEM concept
Unlike classic asymmetric encryption, a KEM doesn't directly encrypt data. It allows establishing a shared secret between two parties, then used to derive a symmetric key.
ML-KEM implementation
ML-KEM-768 sizes
| Element | Size |
|---|---|
| Public key | 1,184 bytes |
| Private key | 2,400 bytes |
| Ciphertext | 1,088 bytes |
| Shared secret | 32 bytes |
These sizes are significantly larger than classic equivalents (an X25519 public key is 32 bytes), but performance remains excellent.
ML-DSA: Quantum-secure signatures
To authenticate data or messages, use ML-DSA (Module-Lattice Digital Signature Algorithm).
Use cases
- JWT token signing
- File integrity verification
- Message authentication
- Certificates and trust chains
ML-DSA implementation
Contextual signature
ML-DSA supports an optional context to bind the signature to a specific use:
ML-DSA-65 sizes
| Element | Size |
|---|---|
| Public key | 1,952 bytes |
| Private key | 4,032 bytes |
| Signature | 3,309 bytes |
Secure Enclave
CryptoKit's ML-KEM and ML-DSA implementations support the Secure Enclave, offering:
- Isolated hardware execution
- Protection against side-channel attacks (timing, side-channel)
- Keys that never leave the Secure Enclave
Secure Enclave key generation
ML-DSA with Secure Enclave
Swift Crypto for servers
For client-server interoperability, use Swift Crypto on the server side. This library provides an API compatible with CryptoKit, including all quantum-secure APIs.
Installation
Server example (Vapor)
Migration and Best Practices
Recommended hybrid approach
Don't switch directly to "all post-quantum". Use the hybrid approach:
Migration checklist
- Cryptographic inventory: Identify all uses of RSA, ECDSA, ECDH in your code
- Prioritization: Start with long-lived data (health, finance, identity)
- Performance testing: ML-KEM/ML-DSA have larger key sizes
- Server compatibility: Verify TLS 1.3 quantum-secure support
- Keychain storage: Adapt serialization for new key sizes
What NOT to do
Official resources
Going further
Post-quantum cryptography is no longer distant preparation — it's a reality in iOS 26. With automatic adoption of quantum-secure TLS and the new CryptoKit APIs, Apple eases the transition.
Key takeaways:
- Automatic TLS — Network connections are already protected if the server supports X25519MLKEM768
- Hybrid HPKE — The high-level API for end-to-end encryption
- ML-KEM / ML-DSA — Low-level APIs for custom protocols
- Secure Enclave — Hardware protection available for all new APIs
- Hybrid approach — Combine classic and post-quantum during transition
In a future article, we'll explore CryptoKit fundamentals: AES-GCM, SHA-256, ECDSA and Keychain storage best practices that remain essential even in the post-quantum era.