ML-KEM Layer: The Quantum-Resistant Fortress

Mental Model: The Magic Lockbox

Imagine you have a lockbox with a magical property:

Any key can lock it
Only YOUR specific key can unlock it
Even if you give Eve a billion years and a supercomputer, she can't make a key from the lock

ML-KEM is that magic lockbox. It's a post-quantum algorithm that resists attacks from both classical and quantum computers.

Why It's Magic

Traditional algorithms like ECDH rely on the discrete logarithm problem. But quantum computers can solve this faster (Shor's algorithm).

ML-KEM uses a different kind of math (lattice problems) that quantum computers can't solve efficiently. It's like changing the rules of the game while keeping the outcome the same.

Why Use ML-KEM in Cascading Cipher?

🎯 The Problem

Quantum computers are getting better:

2019: Google's quantum computer (53 qubits)
2023: IBM's Osprey (433 qubits)
Future: Millions of qubits

Current algorithms (ECDH, RSA) break on large quantum computers:

ECDH-P256: ~128-bit security (classical) → ~60-bit (quantum!)
RSA-2048:  ~112-bit security (classical) → broken instantly (quantum)

If Eve has a quantum computer:

She records all your encrypted messages today
She waits for quantum computers to improve
She breaks ECDH/RSA and decrypts everything

This is harvest now, decrypt later.

🛡️ The ML-KEM Solution

ML-KEM (CRYSTALS-Kyber) provides quantum-resistant key exchange:

Same functionality as ECDH: generate shared secrets
But uses lattice cryptography (quantum-resistant)
NIST standardized in 2022 (FIPS 203)

ML-KEM-768 provides ~128-bit security even against quantum computers!

Where It Fits in the Stack

┌─────────────────────────────────┐
│  🔐 ML-KEM Layer (Quantum Safe) │ ← Post-quantum security
├─────────────────────────────────┤
│  🤝 DH Layer (Key Exchange)     │ ← Classical security
├─────────────────────────────────┤
│  📞 Signal Layer (Ratcheting)   │ ← Forward secrecy
├─────────────────────────────────┤
│  AES Layer (Foundation)         │ ← Encrypts with both keys
└─────────────────────────────────┘

ML-KEM provides the quantum-resistant dimension. If you use ML-KEM + DH, you're safe even if quantum computers improve.

How Lattice Cryptography Works

The Lattice Problem

A lattice is a grid of points in many dimensions:

2D Lattice (simple):
  •   •   •   •   •
    •   •   •   •
  •   •   •   •   •

Shortest Vector Problem (SVP): Given a lattice, find the shortest non-zero vector.

Seems easy, right? For a 2D grid, it is. But ML-KEM uses thousands of dimensions:

High-dimensional lattice (hard to solve):
  •   •   •   •   •   ...   (thousands!)
    •   •   •   •   •   ...   (thousands!)
  •   •   •   •   •   ...   (thousands!)

In high dimensions:

Finding the shortest vector becomes exponentially hard
Even quantum computers struggle

ML-KEM's Lattice: Module-Learning With Errors (MLWE)

ML-KEM uses a specific lattice problem called MLWE:

KeyGen: Alice picks a random lattice (secret) and a distorted version (public)
Encap: Bob uses Alice's public lattice to create a ciphertext (encrypted key)
Decap: Alice uses her secret lattice to decrypt and get the key

Magic: Eve sees only Alice's public lattice and Bob's ciphertext. She must find the shortest vector in a high-dimensional lattice—impossible even on quantum computers.

How ML-KEM Works

Key Generation

// Alice generates a key pair
const aliceKeyPair = await MLKEM768.keyGen()

// Output:
// - alicePublicKey: A distorted lattice description
// - alicePrivateKey: The secret lattice itself
// - alicePrivateKey is ~2400 bytes (much bigger than ECDH!)

Key Encapsulation (Bob sending to Alice)

// Bob wants to send Alice a secret key
const (ciphertext, bobSharedSecret) = await MLKEM768.encap(alicePublicKey)

// ciphertext: ~768 bytes (encrypted encapsulation)
// bobSharedSecret: 32 bytes (the secret key Bob wants to share)

// Bob sends ciphertext to Alice

Key Decapsulation (Alice receives)

// Alice receives ciphertext from Bob
const aliceSharedSecret = await MLKEM768.decap(ciphertext, alicePrivateKey)

// aliceSharedSecret: 32 bytes (should equal bobSharedSecret!)

// Alice and Bob now have the same shared secret!
// Even though Alice never sent her private key!

Using the Shared Secret

// Derive an AES encryption key from the shared secret
const aesKey = await crypto.subtle.importKey(
  'raw',
  sharedSecret,
  'AES-GCM',
  false,
  ['encrypt', 'decrypt']
)

// Encrypt a message
const encrypted = await crypto.subtle.encrypt(
  { name: 'AES-GCM', iv: new ArrayBuffer(12) },
  aesKey,
  plaintext
)
// Secure against both classical and quantum attacks!

Why Quantum Computers Can't Break ML-KEM

Shor's Algorithm vs. LWE

Shor's algorithm (breaks ECDH/RSA):

Solves the discrete logarithm problem
Complexity: O(log⁶ N) (polynomial time!)
On a 2048-qubit quantum computer → breaks RSA in hours

LWE problem (ML-KEM's basis):

No known quantum algorithm is exponentially faster than classical
Best quantum attack: O(2⁴⁰) operations
On a perfect quantum computer → billions of years

Security Comparison

Algorithm	Classical Security	Quantum Security	Status
ECDH-P256	128-bit	60-bit	Broken by quantum
RSA-2048	112-bit	0-bit (instant)	Broken by quantum
ML-KEM-768	192-bit (≈128-bit)	128-bit	Safe

Quantum computers don't help with LWE—they'd need to solve an NP-hard problem, which is impossible for large enough dimensions.

Using the ML-KEM Layer

Basic Usage

import { MLKEMCipherLayer } from '@cascading-cipher/ml-kem-layer'

// Create an ML-KEM layer
const mlKemLayer = new MLKEMCipherLayer()

// Generate a key pair
const keyPair = await mlKemLayer.keyGen()
// keyPair.publicKey: 1184 bytes
// keyPair.privateKey: 2400 bytes

// Send public key to the other person

Sending a Message

// Sender (Bob) encapsulates a shared secret
const (ciphertext, sharedSecret) = await mlKemLayer.encap(alicePublicKey)

// Derive an AES encryption key
const aesKey = await crypto.subtle.importKey(
  'raw',
  sharedSecret,
  'AES-GCM',
  false,
  ['encrypt', 'decrypt']
)

// Encrypt the message
const plaintext = 'Quantum-secure message!'
const encrypted = await crypto.subtle.encrypt(
  { name: 'AES-GCM', iv: new ArrayBuffer(12) },
  aesKey,
  new TextEncoder().encode(plaintext)
)

// Send ciphertext (768 bytes) + encrypted message

Receiving a Message

// Receiver (Alice) decapsulates the shared secret
const sharedSecret = await mlKemLayer.decap(ciphertext, alicePrivateKey)

// Derive the same AES encryption key
const aesKey = await crypto.subtle.importKey(
  'raw',
  sharedSecret,
  'AES-GCM',
  false,
  ['encrypt', 'decrypt']
)

// Decrypt the message
const decrypted = await crypto.subtle.decrypt(
  { name: 'AES-GCM', iv: new ArrayBuffer(12) },
  aesKey,
  encrypted
)

console.log('Decrypted:', new TextDecoder().decode(decrypted))
// "Quantum-secure message!"

Integration with CascadingCipherManager

import { CascadingCipherManager } from '@cascading-cipher/manager'
import { AESCipherLayer } from '@cascading-cipher/aes-layer'
import { DHCipherLayer } from '@cascading-cipher/dh-layer'
import { SignalCipherLayer } from '@cascading-cipher/signal-layer'
import { MLKEMCipherLayer } from '@cascading-cipher/ml-kem-layer'

// Add quantum-resistant layer
const manager = new CascadingCipherManager()

// 1. Classical DH for speed
await manager.addLayer(new DHCipherLayer({
  myPrivateKey: myPrivateKey,
  theirPublicKey: theirPublicKey
}))

// 2. ML-KEM for quantum resistance (backup!)
await manager.addLayer(new MLKEMCipherLayer())

// 3. Signal for forward secrecy
await manager.addLayer(new SignalCipherLayer({
  myKeyPair,
  theirPublicKey,
  rootKey: derivedRootKey
}))

// 4. AES for encryption
await manager.addLayer(new AESCipherLayer())

// Encrypt with quantum resistance
const encrypted = await manager.encrypt(
  'Message safe even in 2050!'
)

// Decrypt with quantum resistance
const decrypted = await manager.decrypt(encrypted)
console.log('Quantum-secure:', decrypted)

Complete Example: Quantum-Resistant Encryption

async function quantumResistantChat() {
  // Generate ML-KEM key pairs
  const aliceKeyPair = await MLKEM768.keyGen()
  const bobKeyPair = await MLKEM768.keyGen()

  // Create managers for both
  const aliceManager = new CascadingCipherManager()
  const bobManager = new CascadingCipherManager()

  // Classic DH layer (fast)
  const dhKeyPair = await crypto.subtle.generateKey(
    { name: "ECDH", namedCurve: "P-256" },
    true,
    ["deriveKey", "deriveBits"]
  )

  // Add all layers (order matters!)
  for (const [manager, myDhKey, theirDhKey, myKemKey, theirKemKey] of [
    [aliceManager, dhKeyPair, dhKeyPair, aliceKeyPair, bobKeyPair],
    [bobManager, dhKeyPair, dhKeyPair, bobKeyPair, aliceKeyPair]
  ]) {
    await manager.addLayer(new DHCipherLayer({
      myPrivateKey: myDhKey.privateKey,
      theirPublicKey: theirDhKey.publicKey
    }))

    await manager.addLayer(new MLKEMCipherLayer({
      myKeyPair: myKemKey,
      theirPublicKey: theirKemKey.publicKey
    }))

    await manager.addLayer(new SignalCipherLayer({
      myKeyPair: myDhKey,
      theirPublicKey: theirDhKey.publicKey
    }))

    await manager.addLayer(new AESCipherLayer())
  }

  // Send 5 messages
  const messages.forEach(msg => {
    const encrypted = await aliceManager.encrypt(msg)
    const decrypted = await bobManager.decrypt(encrypted)
    console.log(`${msg} → ${new TextDecoder().decode(decrypted)}`)
  })

  console.log('\n✅ Secure even if quantum computers break ECDH!')
  console.log('  → ML-KEM still protects!')
}

Advantages and Trade-offs

✅ Advantages

Quantum resistant: Safe even against quantum computers
NIST standard: FIPS 203 (2022) - federally approved
No patents: Fully open, royalty-free
Good security: ~128-bit security against quantum computers
Fast enough: ~0.5ms for keyGen/encap/decap

📉 Trade-offs

Larger keys: 1184 bytes (vs. 65 bytes for ECDH-P256)
Larger ciphertext: 768 bytes (vs. ~32 bytes for ECDH-P256)
Slower: ~2x slower than ECDH
Bigger code: ~10KB vs. ~2KB for ECDH
Newer: Less battle-tested than ECDH/Signal

When to Use ML-KEM

✅ Use When

High security requirements: Healthcare, finance, government
Long-term data storage: Records needed for decades
Regulatory compliance: FIPS 203 requirements
Paranoid security: Future-proofing

⚠️ Maybe Use When

Mixed security: Some messages quantum-protected, some not
Performance不重要: Latency is okay (e.g., email)

❌ Use Alone When

Not recommended: ML-KEM + DH is safer (classical + quantum)

Quiz Time!

🧠 Why can quantum computers break ECDH-RSA but not ML-KEM?

ECDH relies on the discrete logarithm problem, which Shor's algorithm can solve efficiently on quantum computers (polynomial time). ML-KEM relies on lattice problems (LWE), which have no known quantum algorithm exponentially faster than classical attacks. Solving LWE in high dimensions is NP-hard even for quantum computers!

🧠 What's the ML in ML-KEM stand for?

"Module-Learning With Errors". It's a specific type of lattice problem where you learn a "module" (a mathematical structure) with "errors" (noise). The randomness of errors makes it impossible to reverse-engineer the secret, even with quantum computers.

Details

🧠 What if Eve records ML-KEM-encrypted messages and quantum computers become much faster?

Eve still can't decrypt! ML-KEM has post-quantum security—providing ~128-bit protection even if the theoretical best quantum algorithm is used. Current quantum computers would need ~2⁴⁰ operations (billions of years). Even in 2050 with faster computers, it's still infeasible unless there's a mathematical breakthrough (which is unlikely).

🧠 Why not just use ML-KEM instead of DH (why use both)?

Because:

Defense in depth: If one is broken, the other stays secure
Optimization: DH is ~2x faster (use for speed, ML-KEM for backup)
Maturity: ECDH is battle-tested (30+ years), ML-KEM is new
Standards: Most systems use ECDH + ML-KEM (Signal's PQXDH)

You get the best of both: speed (DH) + quantum resistance (ML-KEM).

🧠 What's FIPS 203?

Federal Information Processing Standard 203 (issued by NIST in 2022) standardizing ML-KEM (CRYSTALS-Kyber) for federal government use. It's the official post-quantum key exchange algorithm for US government agencies.

Can You Explain to a 5-Year-Old?

Imagine a magical lockbox:

You have a box with a secret combination
Anyone can use it to lock things
But only YOU know how to unlock it
Even a super-smart robot with "quantum powers" can't figure out the combination
It uses a different kind of math (like a 3D puzzle) that no robot can solve

Unlike normal locks (ECDH) where a "quantum robot" can pick the open, ML-KEM's magic puzzle is unsolvable—like trying to solve a billion-piece Rubik's cube where you can only make one move every second!

Key Takeaways

✅ ML-KEM = post-quantum key exchange: Safe against quantum computers

✅ Lattice cryptography: Uses high-dimensional grid problems (unsolvable)

✅ Module-LWE: The specific lattice problem ML-KEM uses

✅ FIPS 203: NIST standard for federal government use

✅ Larger keys: 1184 bytes (vs. 65 for ECDH)

✅ Slower: ~2x slower than ECDH

✅ Use both: DH (speed) + ML-KEM (quantum-resistant) = best security

✅ Future-proof: Safe even in 2050 when quantum computers improve

✅ Used by: Signal (PQXDH), various messaging apps (adding post-quantum)

Mental Model: The Magic Lockbox​

Why It's Magic​

Why Use ML-KEM in Cascading Cipher?​

🎯 The Problem​

🛡️ The ML-KEM Solution​

Where It Fits in the Stack​

How Lattice Cryptography Works​

The Lattice Problem​

ML-KEM's Lattice: Module-Learning With Errors (MLWE)​

How ML-KEM Works​

Key Generation​

Key Encapsulation (Bob sending to Alice)​

Key Decapsulation (Alice receives)​

Using the Shared Secret​

Why Quantum Computers Can't Break ML-KEM​

Shor's Algorithm vs. LWE​

Security Comparison​

Using the ML-KEM Layer​

Basic Usage​

Sending a Message​

Receiving a Message​

Integration with CascadingCipherManager​

Complete Example: Quantum-Resistant Encryption​

Advantages and Trade-offs​

✅ Advantages​

📉 Trade-offs​

When to Use ML-KEM​

✅ Use When​

⚠️ Maybe Use When​

❌ Use Alone When​

Quiz Time!​

Can You Explain to a 5-Year-Old?​

Key Takeaways​