Post-Quantum Key Management: ML-KEM, ML-DSA, and Three-Key Signing

The quantum clock is ticking. NIST finalized its first set of post-quantum cryptographic standards in August 2024, and organizations worldwide are now confronting the operational reality of migrating from RSA, ECDSA, and ECDH to their quantum-resistant replacements. The standards are ready. The question now is whether your key management infrastructure can actually support them.

This is not an academic exercise. Every enterprise that handles sensitive data, processes financial transactions, or authenticates users is running cryptographic infrastructure that a sufficiently powerful quantum computer could break. The migration to post-quantum cryptography is not a future concern; it is a present engineering challenge with immediate implications for how you generate, store, distribute, rotate, and revoke cryptographic keys.

Understanding the New Primitives

Before we can discuss key management strategy, we need to understand the building blocks. NIST has standardized three primary algorithms that replace the classical primitives most enterprises depend on today.

ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism), published as FIPS 203, replaces key exchange protocols like ECDH and RSA-KEM. Unlike Diffie-Hellman, which relies on the hardness of discrete logarithms, ML-KEM derives its security from the Module Learning With Errors (MLWE) problem. This is a lattice-based problem that remains hard even for quantum computers running Shor's algorithm. ML-KEM comes in three parameter sets: ML-KEM-512 (NIST Level 1), ML-KEM-768 (Level 3), and ML-KEM-1024 (Level 5). Each offers progressively stronger security at the cost of larger key sizes and ciphertexts.

ML-DSA (Module-Lattice-Based Digital Signature Algorithm), published as FIPS 204, replaces RSA and ECDSA signatures. Like ML-KEM, it is built on the MLWE problem. ML-DSA-44 targets Level 2, ML-DSA-65 targets Level 3, and ML-DSA-87 targets Level 5. Public keys range from approximately 1,312 bytes (Level 2) to 2,592 bytes (Level 5), compared to 32 bytes for Ed25519. This is the single largest operational impact of the PQ migration: key sizes increase by orders of magnitude.

SLH-DSA (Stateless Hash-Based Digital Signature Algorithm), published as FIPS 205, provides an alternative signature scheme based on hash functions rather than lattice problems. Its security assumption is minimal: it requires only that the underlying hash function (SHA-256 or SHAKE) is collision-resistant. SLH-DSA signatures are significantly larger (up to 49,856 bytes for the highest security level), but the scheme offers a fundamentally different mathematical basis from lattice-based approaches.

Why Key Size Changes Everything

The most immediate operational challenge of post-quantum key management is size. Classical systems were designed around small keys. An RSA-2048 public key is 256 bytes. An Ed25519 key is 32 bytes. An X25519 shared secret fits in 32 bytes. Enterprise infrastructure, from HSMs to TLS handshakes to certificate chains to database columns, was engineered around these compact artifacts.

Post-quantum changes the calculus dramatically. An ML-KEM-1024 public key is 1,568 bytes. An ML-DSA-87 public key is 2,592 bytes. An SLH-DSA-SHA2-256f signature is 49,856 bytes. When you combine multiple schemes for defense in depth, the raw size of a single attestation bundle can exceed 55,000 bytes.

This is not merely a storage concern. Larger keys mean longer TLS handshakes, more bandwidth for API authentication, higher HSM memory consumption, and increased latency for certificate verification chains. Any key management system designed for classical cryptography will need fundamental architectural changes to accommodate these sizes efficiently.

The Three-Key Architecture: Why One Algorithm Is Not Enough

Here is where the conversation gets more nuanced. Most enterprises, upon learning about the new NIST standards, plan to migrate from ECDSA to ML-DSA and call it done. This is insufficient. Migrating from one single-point-of-failure algorithm to another single-point-of-failure algorithm does not solve the fundamental vulnerability; it merely changes which mathematical assumption you are betting the company on.

The three-key signing architecture addresses this by combining three independent signature schemes, each based on a different mathematical hardness assumption. H33 uses ML-DSA (lattice-based), FALCON (structured-lattice NTRU-based), and SLH-DSA (hash-based). An attestation produced by this architecture is secure unless all three underlying mathematical problems are solved simultaneously. Breaking MLWE lattice problems would compromise ML-DSA, but FALCON (based on NTRU lattices) and SLH-DSA (based on hash collision resistance) would remain intact. Breaking NTRU would still leave ML-DSA and SLH-DSA standing. Only a simultaneous breakthrough against all three independent hardness assumptions would compromise the system.

This is not theoretical paranoia. The history of cryptography is littered with algorithms that were considered secure until they were not. MD5 was widely deployed when collision attacks made it obsolete. SHA-1 followed the same trajectory. RSA key sizes that were considered adequate in 2000 are dangerously small today. Post-quantum algorithms, while rigorously vetted by NIST, are newer and less battle-tested than the classical schemes they replace. Defense in depth through multiple independent mathematical foundations is the responsible engineering choice.

Key Generation at Scale

Generating post-quantum keys is computationally different from generating classical keys. ML-KEM key generation requires sampling from a noise distribution and performing polynomial arithmetic over a module lattice. ML-DSA key generation involves similar operations with additional matrix expansion steps. FALCON key generation is significantly more complex, requiring the generation of NTRU lattice trapdoors using the GPV framework, which involves Gram-Schmidt orthogonalization of high-dimensional lattice bases.

For enterprises generating thousands of keys per second (as in large-scale authentication systems), the computational overhead of PQ key generation can be substantial. FALCON key generation is particularly expensive, often taking several milliseconds per key pair. At scale, this means that key generation must be parallelized, batched, or pre-computed to avoid becoming a throughput bottleneck.

H33 addresses this through pre-computed key pools that generate FALCON key pairs asynchronously and make them available on demand. ML-DSA and SLH-DSA key generation is fast enough to be done in-line for most use cases, but for high-throughput scenarios, the same pooling strategy applies. The key pools are managed with strict entropy accounting to ensure that every key pair is generated from fresh, auditable randomness.

Key Storage and HSM Compatibility

Hardware Security Modules (HSMs) are the backbone of enterprise key management. They provide tamper-resistant storage, access control, and cryptographic acceleration. The problem is that most deployed HSMs were designed for classical algorithms. They have fixed-size key slots, limited memory, and firmware that does not understand ML-KEM or ML-DSA key formats.

The industry is catching up. Thales Luna, Entrust nShield, and AWS CloudHSM have begun adding PQ algorithm support, but adoption is uneven. Some HSMs support ML-KEM but not SLH-DSA. Others support ML-DSA but only at Level 2. None currently offer native three-key bundle management. This means that enterprises adopting a three-key architecture need either HSM firmware upgrades, custom PKCS#11 wrappers, or a software-based key management layer that can interface with HSMs for the algorithms they do support while handling the rest in software.

H33 takes a hybrid approach. Keys that HSMs can handle natively (typically ML-KEM and ML-DSA) are stored in hardware. FALCON and SLH-DSA keys, which require specialized handling, are managed in secure enclaves with software-based access control. The three-key bundle is assembled at signing time, drawing from both hardware and software key stores through a unified API.

Key Rotation and Lifecycle Management

Post-quantum keys have different lifecycle characteristics than classical keys. The larger key sizes mean that rotation events generate more network traffic and storage churn. The computational cost of key generation means that rotation cannot be as frequent as it might be with Ed25519, where generating a new key pair is essentially instantaneous.

For the three-key architecture, rotation is more complex because three independent key pairs must be rotated in coordination. If you rotate ML-DSA but not FALCON, your security posture is temporarily asymmetric. The rotation protocol must ensure that all three keys are updated atomically from the perspective of verifiers, even though the generation of each key pair may take different amounts of time.

H33 implements staged rotation with a key overlap period. New key material is generated for all three schemes in advance. When the rotation event triggers, the signing engine switches to the new three-key bundle atomically, while the old bundle remains valid for a configurable grace period to allow in-flight verifications to complete. This approach avoids both the thundering-herd problem of simultaneous regeneration and the security gap of incremental rotation.

Key Distribution and Certificate Chains

X.509 certificates are the standard mechanism for distributing public keys in enterprise environments. Post-quantum certificates are significantly larger than their classical counterparts. A certificate containing an ML-DSA-87 public key and signed with ML-DSA-87 will be roughly 7 to 8 KB, compared to approximately 1 KB for an RSA-2048 certificate. A three-key certificate bundle containing public keys for all three schemes, along with multi-signature verification data, can reach 15 to 20 KB per certificate.

Certificate chains compound the problem. A typical TLS chain has three certificates (end-entity, intermediate, root). With post-quantum certificates, that chain could exceed 60 KB, compared to the typical 3 to 5 KB for classical chains. This has direct implications for TLS handshake latency, especially on constrained networks or mobile devices.

The H33-74 distillation primitive addresses this by reducing the on-wire representation of a three-key attestation to just 74 bytes. The full cryptographic material is retained in the H33 infrastructure (specifically in the Cachee layer), while the 74-byte distilled form serves as a verifiable pointer that can be expanded on demand. This allows enterprise systems to pass compact attestation tokens through bandwidth-constrained channels while retaining the full cryptographic strength of the three-key architecture.

Revocation in a Post-Quantum World

Key revocation becomes more critical and more complex in the post-quantum era. If a classical key is compromised, the damage is bounded by the key's usage period. If a post-quantum key is compromised, the stakes are potentially higher because the adversary who compromised it may also be stockpiling encrypted traffic for future quantum decryption (the "harvest now, decrypt later" attack). Revocation must be faster and more reliable than in classical systems.

OCSP (Online Certificate Status Protocol) and CRL (Certificate Revocation List) mechanisms work for post-quantum certificates with minor modifications, but the larger signature sizes mean that OCSP responses are bulkier and CRLs grow faster. For high-throughput systems, H33 uses a Cachee-backed revocation layer that provides sub-millisecond revocation checks without the overhead of traditional OCSP responders.

Migration Strategy: Hybrid First, Then Pure PQ

The recommended migration path for most enterprises is hybrid mode: run classical and post-quantum algorithms in parallel during the transition period. This means generating both ECDSA and ML-DSA signatures, establishing both X25519 and ML-KEM shared secrets, and maintaining both classical and PQ certificate chains.

Hybrid mode doubles the key management burden but provides backward compatibility with systems that have not yet migrated. It also provides a safety net: if a PQ algorithm is found to have a vulnerability, the classical algorithm still provides protection (assuming quantum computers are not yet available at scale).

H33 supports hybrid mode natively, with the key management API transparently generating and managing both classical and PQ key material. As downstream systems complete their migration, the classical keys can be phased out through the standard rotation mechanism.

Operational Monitoring and Compliance

Post-quantum key management introduces new monitoring requirements. Key generation entropy must be audited more rigorously because lattice-based schemes are sensitive to bias in random sampling. Key sizes must be tracked to ensure that the correct parameter sets are deployed (an ML-KEM-512 key accidentally deployed where ML-KEM-1024 is required would be a compliance violation). Signature verification times should be monitored because PQ verification is slower than classical verification, and performance regressions can indicate implementation bugs or downgrade attacks.

For regulated industries, post-quantum migration also intersects with compliance frameworks. CMMC 2.0, FedRAMP, and NIST 800-171 are all incorporating post-quantum requirements. The key management system must produce audit logs that demonstrate PQ compliance: which algorithms were used, at what security level, with what key material, and when keys were rotated or revoked.

The Road Ahead

Post-quantum key management is the most significant infrastructure upgrade the cryptographic community has faced since the transition from DES to AES. The algorithms are standardized. The threat is real. The engineering challenges, while substantial, are solvable with the right architecture.

The three-key approach ensures that your security posture is not a single bet on one mathematical assumption. The H33-74 distillation primitive ensures that the overhead of multi-scheme attestation does not become a practical barrier to deployment. And the unified key management API ensures that the operational complexity of managing three independent PQ schemes does not overwhelm your engineering team.

The organizations that start now will have a significant advantage. Post-quantum migration is not a weekend project; it requires careful planning, infrastructure upgrades, and phased rollout. But the alternative, waiting until quantum computers are a reality, is not a strategy. It is a gamble with your organization's most sensitive data.

The primitives are ready. The infrastructure is ready. The question is whether you are.