ML-KEM and ML-DSA
Implementation Guide

ML-KEM and ML-DSA are external NIST post-quantum standards — ML-KEM (FIPS 203) is a lattice-based key encapsulation mechanism and ML-DSA (FIPS 204) is a lattice-based digital signature algorithm, both finalized by NIST in August 2024. H33 does not own or invent these algorithms; H33 implements, conforms to, and verifies against them, and uses ML-DSA as one of three signature families that produce the portable 74-byte post-quantum evidence primitive anchored by H33-74.

Why this guide exists. Classical key exchange (ECDH, RSA-KEM) and classical signatures (RSA, ECDSA, Ed25519) are broken by a large quantum computer. Migrating correctly is subtle — larger keys, constant-time requirements, hybrid deployment, crypto agility — and a wrong implementation silently loses the security guarantee. This page documents H33's implementation choices so the migration stays verifiable.

FIPS 203: ML-KEM Overview

ML-KEM (Module Lattice-based Key Encapsulation Mechanism), formerly CRYSTALS-Kyber, is NIST's standardized post-quantum key encapsulation mechanism replacing ECDH and RSA-KEM. Security relies on the Module Learning With Errors (MLWE) problem, resistant to both classical and quantum attacks.

ML-KEM Parameter Comparison

Parameter	ML-KEM-512	ML-KEM-768	ML-KEM-1024
Security Level	NIST Level 1	NIST Level 3	NIST Level 5
Public Key Size	800 bytes	1,184 bytes	1,568 bytes
Ciphertext Size	768 bytes	1,088 bytes	1,568 bytes
Shared Secret	32 bytes	32 bytes	32 bytes

For most applications, ML-KEM-768 (Level 3) provides the best balance of security and performance.

FIPS 204: ML-DSA Overview

ML-DSA (Module Lattice-based Digital Signature Algorithm), formerly CRYSTALS-Dilithium, replaces RSA, ECDSA, and Ed25519. It uses the "Fiat-Shamir with Aborts" paradigm for secure signature generation.

ML-DSA Parameter Comparison

Parameter	ML-DSA-44	ML-DSA-65	ML-DSA-87
Security Level	NIST Level 2	NIST Level 3	NIST Level 5
Public Key	1,312 bytes	1,952 bytes	2,592 bytes
Signature	2,420 bytes	3,293 bytes	4,595 bytes

Implementation Considerations

Constant-Time Implementation

Both ML-KEM and ML-DSA require constant-time implementations to prevent timing side-channel attacks. Critical operations that must be constant-time include polynomial multiplication, rejection sampling in ML-DSA, ciphertext comparison in ML-KEM decapsulation, and all private key operations.

Key Management

Post-quantum keys are larger than classical keys. An ML-DSA-65 public key is 1,952 bytes compared to 32 bytes for Ed25519. Plan for key rotation with clear expiration dates. Implement key versioning so old signatures can be verified with the correct key version. Consider hybrid schemes during transition.

Hybrid Deployment

During transition, combine classical and post-quantum algorithms. For key exchange, concatenate ECDH and ML-KEM shared secrets. For signatures, create nested signatures: sign with Ed25519, then sign the result with ML-DSA. H33 uses this approach with three signature families providing three independent hardness assumptions.

Performance Optimization

ML-KEM and ML-DSA performance is dominated by polynomial arithmetic over the ring Z_q[X]/(X^n + 1). Properly optimized implementations achieve signing speeds of tens of thousands of operations per second. On ARM processors, NEON SIMD accelerates polynomial operations. On x86, AVX2 and AVX-512 provide similar benefits.

Common Pitfalls

• Weak random number generators. Both algorithms require high-quality randomness. Use the OS CSPRNG (getrandom, /dev/urandom).
• Missing key validation. Always validate public keys before use. Malformed keys can cause undefined behavior.
• Forgetting memory zeroization. Private keys must be zeroized after use. In Rust, use the zeroize crate with ZeroizeOnDrop.
• Hardcoding algorithm parameters. Design with crypto agility. Use abstract interfaces for all cryptographic operations.

H33's Implementation

H33 uses ML-DSA-65 (FIPS 204) as one of three signature families in production, contributing to the 391-microsecond batch attestation latency for 32 authentications. ML-KEM-768 handles key exchange. All implementations are constant-time Rust with memory zeroization and hardware-specific ARM Graviton4 optimizations.

When to Use ML-KEM vs ML-DSA

• Use ML-KEM when you need to establish a shared secret over an untrusted channel — the post-quantum replacement for ECDH and RSA-KEM. Reach for it in TLS-style handshakes and any key exchange.
• Use ML-DSA when you need to prove authorship or integrity — the post-quantum replacement for RSA/ECDSA/Ed25519 signatures. In H33 it is one of three families producing signed evidence.
• Do not treat either as the whole solution. A single lattice family is one hardness assumption. H33 signs evidence with three independent families (ML-DSA and FALCON/FN-DSA and SLH-DSA) and accepts only when all three validate — a 2-of-3 result is a false grant and is rejected, never a majority pass.
• Do not roll your own primitive. If you only need to use post-quantum signatures or verify H33 evidence, consume the Cryptographic APIs or the Verifier CLI rather than re-implementing FIPS 203/204 yourself.

Concept Boundaries

These algorithms are building blocks. To keep the roles distinct:

• The primitive (ML-DSA / ML-KEM / SLH-DSA) is an external NIST/FIPS standard that H33-74 uses to produce the portable evidence — H33-74 does not own or invent the primitive.
• H33-74 produces the portable 74-byte evidence; it does not record or continuously monitor operations — that is HATS.
• H33-74 produces the evidence; the independent verdict on it is rendered by Verification, and the decision made under it is governed by Agent-008.

Frequently Asked Questions

Does H33 own or invent ML-KEM and ML-DSA?

No. ML-KEM (FIPS 203) and ML-DSA (FIPS 204) are external NIST post-quantum standards, finalized August 2024. H33 implements, conforms to, and verifies against them — H33 does not own, invent, or "prove" the standard itself.

If two of the three signature families verify, is the evidence accepted?

No. Acceptance is an AND of all three families: ML-DSA and FALCON/FN-DSA and SLH-DSA must all validate. A 2-of-3 outcome is a false grant and is rejected. There is no majority or threshold acceptance across the crypto families.

Which parameter set should I choose?

For most applications, ML-KEM-768 (NIST Level 3) and ML-DSA-65 (NIST Level 3) give the best balance of security and performance; H33 uses both in production. Move to Level 5 (ML-KEM-1024 / ML-DSA-87) only where a higher assurance floor is required. Design with crypto agility so the parameter set is not hardcoded.

How does this relate to HATS, Verification, and Agent-008?

These algorithms are used by H33-74 to produce portable evidence. HATS records and continuously monitors operations. Verification renders the independent verdict on that evidence. Agent-008 governs the decision made under it. The primitive is not any of these — it is the external standard the evidence is built from.