Skip to main content

Threat Model - ML-KEM Implementation

Overview​

Comprehensive threat model analysis for the ML-KEM cipher layer implementation, including adversary capabilities, attack vectors, and security guarantees.

Last Updated: January 2025

Adversary Model​

Adversary Capabilities​

We consider adversaries with varying capabilities:

  1. Network Adversary (Passive)

    • Can observe network traffic
    • Can perform traffic analysis
    • Cannot modify traffic
    • Cannot decrypt traffic

  2. Network Adversary (Active)

    • Can observe network traffic
    • Can modify network traffic
    • Can inject messages
    • Can perform DoS attacks
    • Cannot break cryptography

  3. Malicious User

    • Legitimate user with malicious intent
    • Can perform operations within limits
    • Can attempt to exploit vulnerabilities
    • Cannot access other users' keys

  4. Compromised Endpoint

    • Attacker controls one endpoint
    • Can access endpoint's keys
    • Can perform operations on behalf of endpoint
    • Cannot access other endpoints' keys

  5. Side-Channel Attacker

    • Can measure timing
    • Can measure power consumption
    • Can measure cache behavior
    • Cannot break cryptography directly

  6. Quantum Computer Attacker

    • Has access to quantum computer
    • Can run Shor's algorithm
    • Can run Grover's algorithm
    • Cannot break ML-KEM (post-quantum secure)

Threat Analysis by Adversary​

Network Adversary (Passive)​

Capabilities:

  • ✅ Can observe encrypted messages
  • ✅ Can observe metadata (message sizes, timing)
  • ✅ Can perform traffic analysis

Protected Against:

  • ✅ Message Confidentiality: Cannot decrypt messages (ML-KEM-768)
  • ✅ Key Derivation: Cannot derive keys (post-quantum security)
  • ✅ Forward Secrecy: Past messages safe (per-message keys)

At Risk:

  • ⚠️ Traffic Analysis: Can observe message patterns
  • ⚠️ Metadata Leakage: Can observe message sizes, timing
  • ⚠️ Performance Timing: Metadata includes processing time

Attack Vectors:

  1. Traffic Analysis

    • Observe message sizes
    • Observe message timing
    • Infer communication patterns

  2. Metadata Analysis

    • Analyze performance timing
    • Analyze input/output sizes
    • Infer system load

Mitigations:

  • ✅ Encryption hides message content
  • ✅ ML-KEM provides post-quantum security
  • ⚠️ Consider padding to hide message sizes
  • ⚠️ Consider removing timing metadata

Network Adversary (Active)​

Capabilities:

  • ✅ Can observe encrypted messages
  • ✅ Can modify network traffic
  • ✅ Can inject messages
  • ✅ Can perform DoS attacks

Protected Against:

  • ✅ Message Forgery: Cannot forge messages (AES-GCM authentication)
  • ✅ Message Modification: Cannot modify messages (AES-GCM authentication)
  • ✅ Replay Attacks: Partially protected (IV reuse prevention)

At Risk:

  • ⚠️ DoS Attacks: No rate limiting
  • ⚠️ Malformed Messages: Partial input validation

Attack Vectors:

  1. DoS via Large Inputs

    • Send 1GB+ plaintext
    • Exhaust memory
    • Crash system

  2. DoS via Rapid Encryption

    • Rapid encryption requests
    • Exhaust CPU/memory
    • Crash system

  3. DoS via IV Tracking

    • Many unique public keys
    • Exhaust IV tracking memory
    • Crash system

  4. Malformed Message Injection

    • Invalid encapsulated keys
    • Invalid IV sizes
    • Invalid salt sizes

Mitigations:

  • ✅ AES-GCM authentication prevents forgery
  • ✅ IV reuse prevention reduces replay risk
  • ❌ Missing: Rate limiting
  • ⚠️ Partial: Input validation

Malicious User​

Capabilities:

  • ✅ Legitimate user with malicious intent
  • ✅ Can perform encryption/decryption operations
  • ✅ Can attempt to exploit vulnerabilities
  • ❌ Cannot access other users' keys

Protected Against:

  • ✅ Other Users' Messages: Cannot decrypt other users' messages
  • ✅ Key Derivation: Cannot derive other users' keys
  • ✅ Message Forgery: Cannot forge messages

At Risk:

  • ⚠️ DoS Attacks: No rate limiting
  • ⚠️ Resource Exhaustion: Can exhaust system resources

Attack Vectors:

  1. DoS via Large Inputs

    • Encrypt 1GB+ data
    • Exhaust memory
    • Impact other users

  2. DoS via Rapid Operations

    • Rapid encryption requests
    • Exhaust CPU/memory
    • Impact other users

  3. IV Tracking Exhaustion

    • Many unique public keys
    • Exhaust IV tracking memory
    • Impact other users

Mitigations:

  • ✅ Cannot access other users' keys
  • ✅ Cannot decrypt other users' messages
  • ❌ Missing: Rate limiting
  • ❌ Missing: Resource quotas

Compromised Endpoint​

Capabilities:

  • ✅ Attacker controls one endpoint
  • ✅ Can access endpoint's private key
  • ✅ Can perform operations on behalf of endpoint
  • ❌ Cannot access other endpoints' keys

Protected Against:

  • ✅ Past Messages: Forward secrecy (per-message keys)
  • ✅ Other Endpoints: Cannot decrypt other endpoints' messages
  • ✅ Key Derivation: Cannot derive other endpoints' keys

No Protection:

  • ❌ Current Session: Can decrypt current session messages
  • ❌ Future Messages: Can decrypt future messages to compromised endpoint

At Risk:

  • ⚠️ Error Messages: May leak information (generic errors only)

Attack Vectors:

  1. Key Extraction

    • Extract private key from compromised endpoint
    • Decrypt all messages to endpoint
    • Impersonate endpoint

  2. Information Leakage

    • ✅ Cannot access development logs (removed)
    • ⚠️ Error messages are generic (limited information)
    • ✅ Cannot access stack traces (not logged)

Mitigations:

  • ✅ Forward secrecy protects past messages
  • ✅ Per-message keys limit exposure
  • ✅ Error message sanitization (generic errors)
  • ❌ Missing: Audit logging

Side-Channel Attacker​

Capabilities:

  • ✅ Can measure timing
  • ✅ Can measure power consumption
  • ✅ Can measure cache behavior
  • ❌ Cannot break cryptography directly

Protected Against:

  • ✅ Constant-Time Operations: Key validation uses constant-time comparison
  • ✅ Crypto Operations: ML-KEM uses constant-time operations
  • ✅ Zeroization: Sensitive data cleared after use

At Risk:

  • ⚠️ Timing Variations: JavaScript timing is variable
  • ⚠️ Error Path Timing: Error paths may have different timing
  • ⚠️ Performance Timing: Metadata includes timing information

Attack Vectors:

  1. Timing Attacks

    • Measure encryption timing
    • Measure decryption timing
    • Infer key validity

  2. Cache Timing Attacks

    • Measure cache behavior
    • Infer memory access patterns
    • Infer key material location

  3. Power Analysis

    • Measure power consumption
    • Infer operations performed
    • Infer key material

Mitigations:

  • ✅ Constant-time key validation
  • ✅ Constant-time comparison utilities
  • ✅ Zeroization reduces exposure window
  • ⚠️ Partial: JavaScript limitations prevent perfect constant-time
  • ⚠️ Partial: Performance timing in metadata

Quantum Computer Attacker​

Capabilities:

  • ✅ Has access to quantum computer
  • ✅ Can run Shor's algorithm
  • ✅ Can run Grover's algorithm
  • ❌ Cannot break ML-KEM (post-quantum secure)

Protected Against:

  • ✅ Shor's Algorithm: ML-KEM is lattice-based, not factoring/discrete log
  • ✅ Grover's Algorithm: Sufficient key size (192-bit equivalent)
  • ✅ Post-Quantum Security: NIST Level 3 security

Attack Vectors:

  1. Shor's Algorithm

    • Attempt to break ML-KEM using Shor's algorithm
    • Result: ML-KEM is resistant (lattice-based)

  2. Grover's Algorithm

    • Attempt to break ML-KEM using Grover's algorithm
    • Result: ML-KEM has sufficient key size (192-bit equivalent)

Mitigations:

  • ✅ ML-KEM is post-quantum secure
  • ✅ NIST Level 3 security (192-bit equivalent)
  • ✅ Resistant to known quantum attacks

Attack Scenarios​

Scenario 1: Timing Attack on Key Validation​

Adversary: Side-Channel Attacker
Attack:

  1. Attacker measures timing of validateKeys() calls
  2. Compares timing for valid vs invalid keys
  3. Infers key validity from timing differences
  4. Uses information for further attacks

Impact: 🟠 HIGH - Information leakage

Mitigation: ✅ Implemented - Constant-time comparison

Status: Protected (best-effort in JavaScript)

Scenario 2: Message Reordering Attack​

Adversary: Network Adversary (Active)
Attack:

  1. Attacker intercepts encrypted messages
  2. Reorders messages
  3. Replays messages out of order
  4. Recipient accepts reordered messages

Impact: 🟠 HIGH - Message reordering

Mitigation: ⚠️ Partial - IV reuse prevention helps, but no AAD

Recommendation: Add AAD to AES-GCM encryption

Scenario 3: DoS via Rapid Encryption​

Security Guarantees​

What IS Guaranteed​

✅ Post-Quantum Security

  • ML-KEM-768 is resistant to quantum computer attacks
  • NIST Level 3 security (192-bit equivalent)
  • Resistant to Shor's and Grover's algorithms

✅ Message Confidentiality

  • Encrypted messages cannot be decrypted without private key
  • ML-KEM provides IND-CCA2 security
  • AES-256-GCM provides authenticated encryption

✅ Message Integrity

  • AES-GCM authentication prevents message modification
  • Message forgery is prevented
  • Tampered messages are rejected

✅ Forward Secrecy

  • Per-message keys provide forward secrecy
  • Past messages remain secure even if current key is compromised

✅ Key Derivation Security

  • HKDF-SHA256 provides secure key derivation
  • Shared secrets are properly derived
  • Keys are properly zeroized after use

What is NOT Guaranteed (Until Fixed)​

❌ DoS Protection

  • ❌ No rate limiting

❌ Replay Protection

  • No message replay detection
  • No nonce/timestamp validation
  • Messages can be replayed

❌ Perfect Constant-Time

  • JavaScript limitations prevent perfect constant-time
  • Timing variations exist
  • Best-effort implementation

❌ Memory Protection

  • Sensitive data not protected from memory dumps
  • JavaScript garbage collection delays memory clearing
  • Memory may remain in heap until GC runs

Risk Assessment​

Overall Risk Level​

Current: 🟡 MEDIUM (P0 fixes implemented)

After P1 Fixes: 🟢 LOW

Risk by Category​

CategoryRisk LevelStatus
Cryptographic Security🟢 LOW✅ Secure
DoS Attacks🔴 HIGH❌ Missing protections
Information Leakage🟠 MEDIUM⚠️ Partial protection
Side-Channel Attacks🟡 MEDIUM⚠️ Best-effort protection
Replay Attacks🟠 MEDIUM⚠️ Partial protection

Recommendations​

Immediate Actions​

  1. Add DoS Protections

    • Rate limiting
    • Resource quotas

  2. Remove Information Leakage

    • Sanitize error messages
    • Remove performance timing

  3. Enhance Replay Protection

    • Add AAD to AES-GCM
    • Implement message replay detection
    • Add nonce/timestamp validation

Short-Term Actions​

  1. Enhance Side-Channel Protection

    • Review all timing-sensitive operations
    • Use constant-time utilities where possible
    • Document timing attack limitations

  2. Add Audit Logging

    • Security event logging
    • Error event logging
    • Performance monitoring

  3. Implement Key Rotation

    • Key rotation API
    • Key versioning
    • Migration strategy

Conclusion​

The ML-KEM implementation provides strong cryptographic security and post-quantum protection, but suffers from operational security vulnerabilities that must be addressed before production deployment.

Key Strengths:

  • ✅ Post-quantum security
  • ✅ Message confidentiality and integrity
  • ✅ Forward secrecy
  • ✅ Proper key derivation

Key Weaknesses:

  • ❌ Missing DoS protections
  • ❌ Missing replay protection
  • ⚠️ Partial side-channel protection
  • ⚠️ Information leakage risks

Recommendation: Fix P0 and P1 issues before production deployment

Document Version: 1.0
Last Updated: January 2025