← Week 2: ML-KEM and ML-DSA

Day 9: ML-KEM Parameters, Key Sizes, and Security Levels

Phase 3 · July 16, 2026

← Week 2: ML-KEM and ML-DSA

Agenda (2–3 hours)

  • Read (45 min): NIST FIPS 203 §4 (parameter sets), §3.3 (security categories)
  • Study (60 min): NIST security levels, parameter tradeoffs, why 768 is the sweet spot
  • Practice (30 min): Key size comparison exercise
  • Challenge (30 min): Parameter recommendation for your service
← Week 2: ML-KEM and ML-DSA

NIST Security Categories

NIST defines 5 security levels for PQC:

Level Classical Equivalent Required Quantum Hardness
1 AES-128 As hard as AES-128 key search
2 SHA-256 collision As hard as SHA-256 collision
3 AES-192 As hard as AES-192 key search
4 SHA-384 collision As hard as SHA-384 collision
5 AES-256 As hard as AES-256 key search

ML-KEM-512 = Level 1, ML-KEM-768 = Level 3, ML-KEM-1024 = Level 5.
NSA CNSA 2.0 requires Level 3 (ML-KEM-768) or higher for all new systems.

← Week 2: ML-KEM and ML-DSA

Why ML-KEM-768 Is the Default

ML-KEM-512 (Level 1):

  • Smallest, fastest
  • 128-bit classical, 128-bit post-quantum
  • Not recommended by NSA for national security use
  • Risk: if lattice cryptanalysis improves, margin is thin

ML-KEM-768 (Level 3):

  • ~192-bit classical, ~182-bit post-quantum
  • 50% larger than 512 variant
  • NSA minimum for new systems
  • Recommended default for most applications

ML-KEM-1024 (Level 5):

  • ~256-bit classical, ~250-bit post-quantum
  • 33% larger than 768 variant
  • Use when handling classified/long-term-sensitive data
  • NSA recommended for TOP SECRET
← Week 2: ML-KEM and ML-DSA

TLS Impact: Key Size Comparison

In a TLS 1.3 ClientHello key_share:

Algorithm Public key (key_share) Ciphertext (server key_share) Total
X25519 32 bytes 32 bytes 64 bytes
ML-KEM-768 1184 bytes 1088 bytes 2272 bytes
X25519+ML-KEM-768 (hybrid) 1216 bytes 1120 bytes 2336 bytes

Impact on TLS handshake: the key_share extension grows from 64 bytes to ~2.3 KB.
For most connections, this fits comfortably in a TCP packet — no extra round trips.

← Week 2: ML-KEM and ML-DSA

Certificate Size Impact

Certificate sizes grow significantly with PQC signatures:

Cert type ECDSA P-256 ML-DSA-44 SLH-DSA-256s
Public key 65 bytes 1312 bytes 64 bytes
Signature 72 bytes 2420 bytes 29,792 bytes
Typical cert ~1 KB ~3.5 KB ~31 KB

A typical 3-cert chain:

  • ECDSA: ~3 KB
  • ML-DSA: ~10.5 KB
  • Mixed (SLH-DSA root, ML-DSA intermediate, ML-DSA leaf): ~35 KB

TLS record size limit is 16 KB per record. A mixed chain may require multiple records.
This has real performance implications — measure, don't assume.

← Week 2: ML-KEM and ML-DSA

Practical Measurement Exercise

# Generate ML-KEM key pair using openssl (with oqs-provider)
# OR use aws-lc-rs in a small Rust program (tomorrow's work)

# Compare key sizes:
openssl genpkey -algorithm ML-KEM-768 | wc -c          # private key
openssl genpkey -algorithm ML-KEM-768 -pubout | wc -c  # public key

# Compare to X25519:
openssl genpkey -algorithm X25519 | wc -c
openssl genpkey -algorithm X25519 -pubout | wc -c

If openssl doesn't have oqs-provider, note the values from the FIPS 203 spec.
You'll do this in Rust tomorrow with actual aws-lc-rs code.

← Week 2: ML-KEM and ML-DSA

Challenge Assignment

Write a "Parameter Selection" section for your migration roadmap:

For each of the three ML-KEM variants, fill in:

ML-KEM-512 ML-KEM-768 ML-KEM-1024
Security level
Public key bytes
Ciphertext bytes
TLS key_share overhead vs X25519
When to use
Recommended for your service?

Conclude with a 1-paragraph recommendation: which variant for your provisioning service's TLS and why.

← Week 2: ML-KEM and ML-DSA

Resources

  • NIST FIPS 203 §4: Parameter sets (definitive reference)
  • NSA CNSA 2.0: algorithm and parameter requirements
  • NIST PQC performance benchmarks: bench.cr.yp.to/supercop.html