# ML-KEM-1024: Maximum Security Parameters

**Source**: https://quantumsequrity.com/blog/ml-kem-1024-deep-dive
**Category**: PQC Algorithms

---

[← Back to Blog](../../blog.html) PQC Algorithms

# ML-KEM-1024: Maximum Security Parameters

10 min read

ML-KEM-1024 is the largest and most conservative parameter set in NIST FIPS 203. It produces a 1568-byte public key, a 1568-byte ciphertext, and a 3168-byte secret key. The shared secret is 32 bytes, the same as the smaller variants. ML-KEM-1024 sits at NIST Category 5, equivalent to AES-256 against quantum brute-force search. This is the parameter set required by the NSA's CNSA 2.0 advisory for national-security-grade systems, and it is what Apple chose for iMessage's PQ3 protocol. For data with multi-decade lifetime or for adversaries expected to have unusually capable future quantum computers, ML-KEM-1024 is the right choice.

This article walks through every parameter, explains when to pick 1024 over 768, and shows how QNSQY Business uses ML-KEM-1024 in critical-data scenarios.

## The Up-Armored SUV Analogy

Picture a fleet of vehicles for different missions. The compact sedan (ML-KEM-512) does daily errands. The standard sedan (ML-KEM-768) handles family commutes and long road trips. The up-armored SUV (ML-KEM-1024) carries cargo into a war zone. It costs more, weighs more, and burns more fuel, but it survives the worst-case scenario.

ML-KEM-1024 is the up-armored option. Most users do not need it. National security organizations, militaries, treaty signatories, and critical infrastructure operators do. The CNSA 2.0 advisory from the NSA, dated September 2022, mandates Category 5 algorithms for national-security systems by 2035, which means ML-KEM-1024 in the KEM slot.

### Why the Highest Category Is Sometimes the Right Default

For data that must remain confidential for 50 to 100 years, the conservative engineering choice is to overshoot today's threat assessment. Quantum computing improvements are not perfectly predictable. Lattice cryptanalysis advances are not perfectly predictable. By picking Category 5, you give yourself a margin equal to the difference between AES-256 and AES-192 worth of effort. That margin can absorb future surprises.

## The Numbers in Detail

ML-KEM-1024 parameters from FIPS 203, Section 8:

| Parameter | Value | Notes |
|-----------|-------|-------|
| n (polynomial degree) | 256 | Same across all three parameter sets |
| q (modulus) | 3329 | Same across all three parameter sets |
| k (module rank) | 4 | Largest of the three sets |
| eta1 | 2 | Centered binomial distribution width |
| eta2 | 2 | Centered binomial distribution width |
| du | 11 | Compression bits for ciphertext component u (higher than 768) |
| dv | 5 | Compression bits for ciphertext component v (higher than 768) |
| Public key | 1568 bytes | k * 12 * 32 + 32 = 1536 + 32 |
| Secret key | 3168 bytes | Includes encrypted public key copy |
| Ciphertext | 1568 bytes | du * k * 32 + dv * 32 = 1408 + 160 |
| Shared secret | 32 bytes | After SHA3-256 expansion |
| Decryption failure probability | < 2^(-174) | Practical security: virtually zero |

The increase from k=3 to k=4 doubles the lattice dimension over ML-KEM-512 and pushes the underlying lattice problem into Category 5 territory. The compression bits du and dv are also bumped to keep the ciphertext error budget healthy at the higher dimension.

### Symmetry Between Public Key and Ciphertext

Notice that ML-KEM-1024's public key and ciphertext are both 1568 bytes. This is a deliberate parameter-tuning result; the higher du, dv compression brings ciphertext size up to match. The total handshake bytes are higher than for ML-KEM-768, which is a real bandwidth cost in TLS deployments.

## Security Level: NIST Category 5

NIST Category 5 means the scheme is at least as hard to break as AES-256 in terms of computational effort. The NIST FIPS 203 analysis gives ML-KEM-1024 an estimated 2^206 classical bit-strength and 2^174 quantum bit-strength against the best known lattice attacks.

| Category | Reference | Approximate quantum bit-strength |
|----------|-----------|----------------------------------|
| Category 1 | AES-128 key search | ~64 bits (Grover halving) |
| Category 3 | AES-192 key search | ~96 bits |
| Category 5 | AES-256 key search | ~128 bits |

Category 5 corresponds to 128-bit post-quantum security floor, which is the threshold most regulators consider sufficient for the most sensitive data over the longest retention periods.

### CNSA 2.0 Mandate

The NSA's CNSA 2.0 advisory, "Announcing the Commercial National Security Algorithm Suite 2.0," specifies that national-security systems must transition to Category 5 PQC by 2035. This means:

| CNSA 2.0 algorithm | Required parameter set | Standard |
|--------------------|------------------------|----------|
| KEM | ML-KEM-1024 | NIST FIPS 203 |
| Signature | ML-DSA-87 | NIST FIPS 204 |
| Symmetric | AES-256-GCM | FIPS 197 |
| Hash | SHA-384 or SHA-512 | FIPS 180-4 |

For commercial entities working with the US Department of Defense or with classified information, CNSA 2.0 sets the floor. Choosing ML-KEM-1024 today means you are aligned with the highest published bar.

## When to Pick ML-KEM-1024

Pick ML-KEM-1024 when:

- You handle CNSA 2.0-relevant national security material.
- Data lifetime exceeds 50 years (genealogical, historical, treaty texts).
- Your customers explicitly require Category 5 protection.
- The bandwidth and storage cost of larger keys and ciphertexts is acceptable.
- Apple iMessage PQ3 alignment is desired.
- You want the maximum margin against unexpected lattice cryptanalysis advances.

## When NOT to Pick ML-KEM-1024

Skip ML-KEM-1024 if:

- Bandwidth is constrained (mobile, satellite, IoT). Use ML-KEM-768 instead.
- TLS handshakes need to fit in a single IP packet. Use ML-KEM-768 instead.
- Compute cost is a concern (smart cards, very low-power microcontrollers).
- Data lifetime is under 10 years. ML-KEM-512 or ML-KEM-768 is plenty.
- You are matching defaults set by the wider TLS ecosystem (which is ML-KEM-768).

## Speed and Bandwidth Comparison

Numbers from Open Quantum Safe liboqs benchmarks on a Skylake-class x86 CPU at 3 GHz:

| Operation | ML-KEM-512 | ML-KEM-768 | ML-KEM-1024 |
|-----------|------------|------------|-------------|
| Keygen | ~14 microseconds | ~25 microseconds | ~38 microseconds |
| Encapsulate | ~16 microseconds | ~28 microseconds | ~44 microseconds |
| Decapsulate | ~12 microseconds | ~22 microseconds | ~36 microseconds |

The compute difference is small in absolute terms. The bandwidth difference is more significant.

| Quantity | ML-KEM-512 | ML-KEM-768 | ML-KEM-1024 |
|----------|------------|------------|-------------|
| Public key | 800 bytes | 1184 bytes | 1568 bytes |
| Ciphertext | 768 bytes | 1088 bytes | 1568 bytes |
| One handshake total | ~1568 bytes | ~2272 bytes | ~3136 bytes |
| Per-day at 1M handshakes | 1.46 GB | 2.12 GB | 2.92 GB |

For high-traffic services, the extra GB per day adds up. For low-volume but high-stakes communications (treaty texts, archival storage), the cost is irrelevant.

### Why TLS Did Not Pick 1024

The Cloudflare team's analysis explained that ML-KEM-1024 handshakes occasionally exceed the standard 1500-byte IP MTU, which can trigger fragmentation. Fragmented TLS handshakes have a small but real failure rate on misconfigured networks. ML-KEM-768 stays comfortably under the boundary.

For QNSQY's file encryption use case, MTU fragmentation does not apply. The ciphertext sits inside an encrypted file, and the size cost is just storage. So QNSQY Business defaults to ML-KEM-768 for general use but supports ML-KEM-1024 for users who specifically request maximum margin.

## Apple iMessage PQ3

Apple's iMessage PQ3 protocol, announced in February 2024, uses ML-KEM-1024. Apple's reasoning was that iMessage handshakes are infrequent compared to web TLS, so the bandwidth cost is negligible per session. The peace of mind of Category 5 was worth the per-handshake byte cost.

PQ3 also uses periodic ratcheting to limit the impact of any future key compromise. The ML-KEM-1024 keys rotate every few messages, which means even a future Shor's-algorithm-equipped attacker who recovers one keyset only learns a small slice of conversation history.

## How QNSQY Uses ML-KEM-1024

QNSQY Pro and Business support ML-KEM-1024 in hybrid mode (paired with X25519). Business additionally supports pure-PQC ML-KEM-1024 with no classical backup, for users who want a 100% PQC encryption posture.

| QNSQY Tier | ML-KEM-1024 hybrid | ML-KEM-1024 pure-PQC | File size |
|------------|---------------------|----------------------|-----------|
| Free | No (only 512) | No | 100MB |
| Pro | Yes (opt-in) | No | 10GB |
| Business | Yes | Yes | Unlimited |

For organizations doing CNSA 2.0 alignment work, the recommendation is QNSQY Business with ML-KEM-1024 hybrid for general data and ML-KEM-1024 pure-PQC for top-tier classified material where classical fallback is undesirable.

### Hybrid X25519 + ML-KEM-1024

The hybrid construction combines X25519's 32-byte shared secret with ML-KEM-1024's 32-byte shared secret using HKDF-SHA-256. The combined key is the input to AES-256-GCM. Total handshake size is ML-KEM-1024 (1568 + 1568 = 3136) plus X25519 (32 + 32 = 64), so about 3200 bytes. Compared to ML-KEM-768 hybrid at about 2300 bytes, the bandwidth premium is roughly 40%.

## Storage Cost in Long-Term Archives

For an organization holding millions of files encrypted under ML-KEM-1024, the per-file overhead is roughly 1568 bytes of ciphertext plus 32 bytes of X25519 plus a small fixed header. Compared to ML-KEM-768 the per-file extra cost is about 480 bytes. For 10 million files, that is around 4.8 GB of additional storage. For most archival services, this is irrelevant; storage is cheaper than the security margin.

| Archive size | ML-KEM-768 ciphertext overhead | ML-KEM-1024 ciphertext overhead | Storage premium |
|--------------|--------------------------------|---------------------------------|------------------|
| 10,000 files | 11 MB | 16 MB | 5 MB |
| 1 million files | 1.1 GB | 1.6 GB | 480 MB |
| 100 million files | 110 GB | 160 GB | 48 GB |

For comparison, the difference between RSA-2048 and RSA-4096 in classical archival was much larger (256 bytes vs 512 bytes per signature), and that was always considered acceptable. ML-KEM parameter selection should not be storage-driven.

## Why Parameter Choice Is a 30-Year Decision

When you encrypt a file with ML-KEM-1024 today, you are committing to that parameter set for the lifetime of the file. To change parameters, you must decrypt and re-encrypt. For active data that gets touched often, this is fine. For long-term archives that may sit untouched for decades, parameter choice becomes a long-lived commitment.

The conservative approach, recommended by NIST in their migration guidance and aligned with NSA CNSA 2.0, is to pick the parameter set whose security category matches or exceeds the data's required confidentiality lifetime. For 50-year archives, Category 5 is the safe bet. For 100-year archives, Category 5 is the only option that exists today, and even then, organizations should plan for re-encryption sometime in the 2050s if a higher category appears.

## Migration Sequencing Within an Organization

For an organization migrating from RSA-2048 to ML-KEM, the typical sequence is:

| Phase | Action | Duration |
|-------|--------|----------|
| 1 | Inventory all RSA/ECDH usage points | 2-4 weeks |
| 2 | Pilot ML-KEM-768 hybrid in non-critical traffic | 4-8 weeks |
| 3 | Roll ML-KEM-768 hybrid to production for general data | 3-6 months |
| 4 | Identify Category 5 use cases (top secret, treaty texts, long archives) | 1-2 months |
| 5 | Deploy ML-KEM-1024 hybrid for those use cases | 2-3 months |
| 6 | Migrate existing archives at the appropriate category | 6-24 months |

Each phase has its own validation gates, particularly around interoperability with vendors and partners. The total elapsed time for a large organization to fully transition is typically 18-36 months.

## Frequently Asked Questions

### Is ML-KEM-1024 too slow for a phone?
No. Even on low-end phones, ML-KEM-1024 keygen takes well under a millisecond. Apple ships it in iMessage on every iPhone supporting iOS 17.4 and later. Performance is not the limiting factor.

### Why does CNSA 2.0 require ML-KEM-1024 specifically?
CNSA 2.0 mandates Category 5 PQC for national security. Among NIST-standardized KEMs, ML-KEM-1024 is the only Category 5 option. HQC-256 (an alternative KEM standardized later) also reaches Category 5 and is allowed.

### Can ML-KEM-1024 ciphertexts fit in a single TLS record?
Single TLS records can hold up to 16384 bytes, so yes, ML-KEM-1024's 1568-byte ciphertext fits easily. The concern about ML-KEM-1024 in TLS is fragmentation across multiple packets at the IP layer, not at the TLS layer.

### How does ML-KEM-1024 compare to ML-KEM-768 in real attack scenarios?
The known attacks on Module-LWE scale exponentially in the lattice dimension. Going from ML-KEM-768's dimension (768) to ML-KEM-1024's dimension (1024) increases attack cost by an enormous factor, far more than the 2x increase suggested by the parameter names. The Category 3 to Category 5 jump is significant.

### What if I want to migrate from ML-KEM-768 to ML-KEM-1024 later?
QNSQY Pro and Business let you re-encrypt files at any parameter level. The plaintext is recovered, the new key is generated, and the new ciphertext written. Existing 768 files remain decryptable; new files use 1024. There is no algorithmic obstacle.

## Sources

1. NIST FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard (August 2024). [https://csrc.nist.gov/pubs/fips/203/final](https://csrc.nist.gov/pubs/fips/203/final)
2. NSA CNSA 2.0 Cybersecurity Advisory (September 2022). [https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF](https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF)
3. Apple Security Engineering, "iMessage with PQ3" (February 2024). [https://security.apple.com/blog/imessage-pq3/](https://security.apple.com/blog/imessage-pq3/)
4. Bos, J. et al. "CRYSTALS-Kyber Algorithm Specifications." NIST PQC Round 3 (2021). [https://pq-crystals.org/kyber/data/kyber-specification-round3-20210804.pdf](https://pq-crystals.org/kyber/data/kyber-specification-round3-20210804.pdf)
5. NIST IR 8413, Status Report on the Third Round of the NIST Post-Quantum Cryptography Standardization Process (2022). [https://csrc.nist.gov/pubs/ir/8413/upd1/final](https://csrc.nist.gov/pubs/ir/8413/upd1/final)
6. Cloudflare Research, "Post-quantum cryptography with X25519MLKEM768" (2024). [https://blog.cloudflare.com/post-quantum-key-agreement/](https://blog.cloudflare.com/post-quantum-key-agreement/)

## Related Articles

- [ML-KEM Explained](../ml-kem-explained.html)
- [Hybrid Encryption Explained](../hybrid-encryption.html)
- [Lattice-Based Cryptography Explained](../lattice-based-cryptography-explained.html)
- [HQC Explained](../hqc-explained.html)
- [NIST FIPS Guide](../nist-fips-guide.html)

---

### Protect Your Data Before Q-Day Arrives

QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.

[Try QNSQY](../../pricing.html)