Post-Quantum Key Management: The Three-Key Problem

NIST standardized three families of post-quantum algorithms. Each rests on a different mathematical hardness assumption. If one family breaks, the others hold. Running one algorithm is a bet. Running three is insurance. Here is how three-key signing works, why key hierarchies matter, and how 74 bytes anchor the entire system.

One Algorithm Is a Single Point of Failure

The most common mistake in post-quantum migration is picking one algorithm and deploying it everywhere. ML-DSA for signatures. ML-KEM for key exchange. Done. Ship it.

That approach replaces one single point of failure (RSA or ECDSA, both breakable by Shor's algorithm) with another single point of failure (lattice-based cryptography, breakable if the Module Learning With Errors problem falls). You have not eliminated the structural risk. You have moved it.

NIST did not standardize one algorithm. NIST standardized three families, deliberately chosen to rest on independent mathematical foundations:

• Lattice-based (MLWE): ML-KEM (FIPS 203) for key encapsulation, ML-DSA (FIPS 204) for digital signatures. Both rely on the hardness of structured lattice problems over polynomial rings.
• NTRU lattice-based: FALCON (selected in Round 3, standardization in progress). Relies on the hardness of short integer solution problems over NTRU lattices — a related but distinct mathematical structure from MLWE.
• Hash-based: SLH-DSA (FIPS 205), formerly SPHINCS+. Security reduces entirely to the collision resistance and preimage resistance of the underlying hash function. No algebraic structure. No lattice. No number theory. Just hashing.

The point is not that any single family is weak. Each passed years of NIST evaluation. The point is that cryptanalysis is unpredictable. Lattice cryptography is younger than RSA was when it was deployed at scale. A breakthrough against MLWE — however unlikely — would break ML-KEM and ML-DSA simultaneously. But it would not touch SLH-DSA, which has nothing to do with lattices. And it would not break FALCON, whose NTRU structure requires a different attack strategy even though both involve lattices.

Three families. Three independent mathematical bets. Breaks if and only if MLWE lattices, NTRU lattices, and stateless hash functions are simultaneously broken. That is the security model.

The Three Families

Each family offers different tradeoffs in key size, signature size, signing speed, and verification speed. Understanding these tradeoffs is essential for designing a key management system that uses all three without creating a performance bottleneck.

ML-DSA-65 is the workhorse. Fast signing, fast verification, moderate sizes. It is the default choice for high-throughput attestation where you need millions of signatures per second. The lattice structure allows efficient batch operations.

FALCON-512 has the most compact signatures — 690 bytes versus 3,309 for ML-DSA. The tradeoff is implementation complexity: FALCON requires high-precision floating-point sampling during key generation and signing, which makes constant-time implementation harder. It occupies a distinct mathematical niche from ML-DSA because NTRU lattices have different algebraic structure than MLWE lattices.

SLH-DSA-SHA2-128f is the conservative anchor. Its signatures are large — 17KB — and signing is slow relative to the lattice schemes. But its security rests on the most battle-tested assumption in all of cryptography: hash functions work. No algebraic structure to attack. No polynomial rings. No number theory. If SHA-256 is collision-resistant and preimage-resistant, SLH-DSA is secure. That simplicity is the point.

Three-Key Signing: How It Works

Three-key signing is not three independent signatures stapled together. It is a nested construction where each layer signs over all previous layers, creating a chain of commitments that cannot be selectively peeled apart.

The signing procedure:

1. Layer 1 — ML-DSA. Sign the message M with ML-DSA-65 to produce signature S1. This is the fast path. ML-DSA dominates throughput in batch scenarios.
2. Layer 2 — FALCON. Sign the concatenation M || S1 with FALCON-512 to produce signature S2. FALCON now commits to both the original message and the ML-DSA signature. An attacker who breaks ML-DSA and forges a different S1' cannot use it without also forging S2.
3. Layer 3 — SLH-DSA. Sign the concatenation M || S1 || S2 with SLH-DSA-SHA2-128f to produce signature S3. The hash-based signature now commits to the entire chain. This is the anchor of last resort.

The combined signature bundle is (S1, S2, S3) — approximately 21,087 bytes total (3,309 + 690 + 17,088).

Verification checks all three independently:

1. Verify S1 against M with ML-DSA public key
2. Verify S2 against M || S1 with FALCON public key
3. Verify S3 against M || S1 || S2 with SLH-DSA public key

All three must pass. If any single family is compromised, the attacker still cannot produce valid signatures for the other two families. The nesting ensures that a forged inner signature propagates into a verification failure at the outer layers.

Key Exchange: ML-KEM

Signing authenticates. Key exchange establishes shared secrets. These are separate concerns with separate key material, and conflating them is a design error that classical cryptography made routinely (RSA was used for both, leading to decades of confused key management).

ML-KEM (FIPS 203) handles key encapsulation. The sender encapsulates a shared secret under the recipient's public key. The recipient decapsulates with their private key. The shared secret feeds into AES-256-GCM for symmetric encryption.

ML-KEM-768 is the default for most applications. Encapsulation takes approximately 0.05ms on Graviton4. Decapsulation takes approximately 0.06ms. These are fast enough that key exchange is never the bottleneck in a post-quantum protocol.

The critical design point: ML-KEM keys are separate from ML-DSA keys. An entity that holds your ML-KEM public key can send you encrypted messages. An entity that holds your ML-DSA public key can verify your signatures. These are different capabilities, managed by different key hierarchies, with different rotation schedules and different access controls.

Key Hierarchy: Separation of Concerns

A post-quantum system has three distinct key hierarchies, and they must remain independent. Mixing them — deriving signing keys from exchange keys, or using FHE keys for attestation — creates cross-hierarchy dependencies that amplify the impact of any single compromise.

Hierarchy 1: FHE Keys (Computation)

BFV, CKKS, and TFHE key material. These keys enable encrypted computation — addition, multiplication, rotation on ciphertexts. They are large (megabytes for evaluation keys), computationally expensive to generate, and never leave the computation boundary. An entity with FHE keys can compute on encrypted data. It cannot read the plaintext. It cannot forge attestations. It cannot intercept transport.

Hierarchy 2: PQ Signing Keys (Attestation)

ML-DSA, FALCON, and SLH-DSA key material. These keys produce the three-key signature bundle that attests computation results. An entity with signing keys can prove that a computation happened, that it was authorized, and that the result has not been tampered with. It cannot decrypt data. It cannot perform encrypted computation.

Hierarchy 3: PQ Exchange Keys (Transport)

ML-KEM key material plus AES-256-GCM session keys. These keys protect data in transit. An entity with exchange keys can establish secure channels and encrypt payloads. It cannot verify attestations. It cannot compute on encrypted data.

HD Key Derivation for Post-Quantum

Managing three key hierarchies with three families each means managing at least nine key pairs per entity. In a multi-tenant system with key rotation, the number grows rapidly. Without hierarchical deterministic (HD) derivation, key management becomes operationally intractable.

HD key derivation follows the BIP-32 pattern adapted for post-quantum key structures:

1. Master seed. One 256-bit random seed per entity, generated from a CSPRNG with at least 256 bits of entropy. This is the single backup target.
2. Family derivation. The master seed derives three family-specific sub-seeds via HKDF-SHA3-256 with domain-separated labels: "h33/mldsa", "h33/falcon", "h33/slhdsa". Each sub-seed generates key material appropriate to its family's key generation algorithm.
3. Purpose derivation. Within each family, child keys are derived for specific purposes: attestation, transport, rotation, revocation. The derivation path encodes the purpose, allowing selective key exposure without compromising the master seed.
4. Index derivation. Sequential indices generate an unlimited number of child keys per purpose. Key rotation creates a new index. Old keys are revoked but the derivation tree is preserved for audit.

One seed. Unlimited key tree. Backup one seed, recover everything. The HD structure means that a key management system does not store thousands of independent keys — it stores one seed and derives on demand.

The adaptation from BIP-32 to post-quantum is non-trivial. BIP-32 derives 256-bit scalars for elliptic curve keys. Post-quantum keys have different structures: ML-DSA keys involve polynomial vectors over module lattices, FALCON keys involve NTRU basis pairs, SLH-DSA keys are seeds for hash-based tree generation. The derivation function must output sufficient entropy for each family's key generation algorithm, which is why HKDF with family-specific labels is used rather than direct BIP-32 child key derivation.

H33-74: Three Keys in 74 Bytes

The three-key signature bundle is approximately 21KB. That is not a permanent storage cost. It is a transient verification cost.

Every computation in the H33 platform is attested with all three families. The full three-key signature is verified at attestation time — all 21KB are generated, transmitted, and checked. Then the H33-74 substrate compresses the commitment to 74 bytes: 32 bytes anchored on-chain, 42 bytes stored in Cachee.

The 285x compression is not lossy. The 74-byte commitment cryptographically binds the full three-key signature, the computation result, the authorization context, and the routing decision. Anyone with the 74-byte commitment can verify that a specific computation was attested by all three families at a specific time. The ephemeral signatures are large but transient. The permanent record is 74 bytes. Forever.

This matters for cost. On Bitcoin, storing 21KB per attestation is economically prohibitive. Storing 32 bytes is routine. The substrate patent makes three-key signing economically viable for high-throughput systems by decoupling verification cost (21KB, paid once) from storage cost (74 bytes, paid forever).

Migration Path: Classical to Post-Quantum

You do not rip and replace. Every production system that has attempted a flag-day cryptographic migration has either failed or caused an outage. The correct approach is hybrid: run both classical and post-quantum in parallel, then phase out classical when ready.

The migration has four phases:

1. Inventory. Catalog every key, every algorithm, every certificate, every signing operation in the system. You cannot migrate what you cannot find. Most organizations discover 3–5x more cryptographic touchpoints than they expected.
2. Hybrid generation. Generate PQ key pairs alongside existing RSA/ECDSA keys. Every entity now has classical keys (for backward compatibility) and PQ keys (for forward security). Key management systems must track both.
3. Dual verification. Produce both classical and PQ signatures. Verifiers check both. If either fails, the operation fails. This phase catches integration bugs, performance regressions, and key management errors without risking availability. The dual signature is larger, but the tradeoff is safety.
4. Classical deprecation. When the PQ stack has been in production long enough to establish confidence — and when classical algorithms are formally deprecated or quantum computers reach sufficient scale — stop generating classical signatures. Verifiers accept PQ-only. Classical keys are archived for historical verification but no longer used for new operations.

H33's hybrid approach supports all four phases with zero downtime. The three-key signing infrastructure accepts classical co-signatures during the transition period. The substrate commitment anchors both the PQ attestation and the classical co-signature in the same 74-byte record. When classical keys are dropped, the substrate format does not change — the classical fields become zero-filled.

The Design Principle

Post-quantum key management is not "use ML-DSA instead of ECDSA." It is a structural redesign of how keys are generated, derived, stored, rotated, and used. Three families for signing. One family for exchange. Independent hierarchies for computation, attestation, and transport. Hierarchical deterministic derivation from a single seed. Hybrid migration with no flag day.

And at the end of the pipeline: 74 bytes. Three independent mathematical bets, compressed into a permanent commitment that costs less to store than a tweet.

That is the three-key problem, solved.