Seeds, Expanded Keys and Key Stores: Where Post-Quantum Private Keys Live

With classical algorithms, nobody asked what form a private key should take. An elliptic-curve private key is one number; a Rivest-Shamir-Adleman (RSA) private key has a well-worn encoding that every tool reads. The new post-quantum standards change that. A private key for Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) or Module-Lattice-Based Digital Signature Algorithm (ML-DSA) can be kept as a short random seed, as a much larger expanded key computed from that seed, or as both. The choice looks like a storage detail, but it decides whether the key can ever move to another library or key store, how it must be checked when imported, and which managed services can hold it at all. This article treats the private key as an operational object: its forms, its encodings, the key stores that support it as of October 2026, and the rules that keep it, and the AI agents that use it, safe.

What each tool writes by default

Why a post-quantum private key can exist as a short seed, a large expanded key or both, why expansion only runs one way, and what the import checks of FIPS 203 can and cannot prove are analysed in two Research articles, 'ML-DSA in Certificates and Tokens' and 'Keys You Did Not Generate'; this article starts from the practical consequence, which is that the form your keys end up in is usually decided by tool defaults that nobody on the team chose.

Those defaults differ between ecosystems, and some changed during 2026. The Java Development Kit (JDK) wrote ML-KEM and ML-DSA private keys only in expanded form when the algorithms arrived in JDK 24. JDK 25.0.4, released on 21 July 2026, switched the default to the seed form, controlled by two security properties, jdk.mlkem.pkcs8.encoding and jdk.mldsa.pkcs8.encoding, with the values seed, expandedKey or both. Oracle's release notes warn that older JDK releases will not accept the new seed-form keys unless the property is set to expandedKey and existing keys are converted with KeyFactory.translateKey.

Other ecosystems chose differently. The Python cryptography package serialises ML-KEM and ML-DSA private keys only in seed form, never the expanded one, and loads them with from_seed_bytes. Go's ML-KEM decapsulation key serialises to its 64-byte seed. .NET 10 exposes both forms explicitly: ExportPrivateSeed and ExportDecapsulationKey for ML-KEM, ExportMLDsaPrivateSeed and ExportMLDsaPrivateKey for ML-DSA. OpenSSL keeps the seed by default and lets administrators change what it writes and accepts through its retain_seed, prefer_seed and output_formats settings for each algorithm.

The practical result is that an estate using more than one language can end up holding keys in several forms without anyone deciding it, and a key generated by JDK 24 can never be exported as a seed. Record the form for every key class, and set it explicitly wherever the tool offers a setting.

To see what a key file actually contains, inspect it rather than trusting its name. The IETF private-key formats encode the seed, the expanded key and both as differently tagged choices inside the PKCS#8 container, so a generic structure dump, such as the output of openssl asn1parse, shows which form is present. Make that check part of the inventory, and flag every long-lived key whose file carries no seed, because those are the keys that will need re-keying rather than migration.

A custody and backup checklist by key store

Where a private key lives decides what custody even means. In a managed cloud key management service (KMS), such as Amazon Web Services (AWS) KMS or Google Cloud KMS, post-quantum private keys cannot be exported at all, so backup is the provider's own durability and the continuity plan is rotation: create a new key, publish its public half and move signers to it. AWS's signing documentation also tells callers to record which key and which signing algorithm produced each signature, because both are needed to verify it later.

In a hardware security module (HSM), a tamper-resistant device that keeps keys inside its own boundary, backup usually means wrapping keys, that is encrypting them, under a key held by another module of the same vendor family. Whether a given firmware version wraps post-quantum keys, and in which form, is product-specific, so this part of the checklist has to be filled in per product and proven with a throwaway key rather than assumed from a datasheet.

For keys held in software, the seed is the whole key: anyone who obtains it can regenerate the private key. Store it encrypted, for example as an encrypted PKCS#8 file, store the parameter set next to it because the same seed expanded under a different parameter set gives an unrelated key, and keep it out of logs, crash dumps, traces and anything an AI agent can read.

1. For every key, record algorithm, parameter set, stored form, store, owner and creation date.
2. Managed KMS: confirm the key is non-exportable, write the rotation procedure, and store key identifier and signing algorithm with every signature.
3. HSM: wrap, back up and restore a throwaway post-quantum key on the exact firmware before generating production keys.
4. Software keys: encrypt the seed at rest, keep the parameter set with it, and limit who can read it.
5. Once a year, rehearse recovery: restore or rotate, then sign or decapsulate a test value with the result.

A migration runbook between tools and stores

Moving post-quantum keys between libraries, key stores or providers fails in quiet ways, so it deserves a runbook rather than a copy command. The steps below are cheap with a throwaway key and expensive to discover in production.

Three failures recur. A key file in the both form can load as one key in a tool that prefers the seed and as another in a tool that trusts the expanded copy, if the two halves disagree; comparing public-key fingerprints across tools catches it. A newer tool writes seed-form keys that an older one rejects, exactly as the JDK 25.0.4 release notes describe for earlier JDKs; the import step of the rehearsal catches it, and the fix is an explicit encoding setting, not a downgrade. And a key that was only ever stored expanded cannot reach a seed-only consumer at all; that one cannot be fixed, only scheduled for re-keying, which is why it belongs on the plan early.

1. Inventory every consumer of the key and the form each one reads and writes.
2. Export a throwaway key in every form the source allows and import it into every target.
3. Compute a fingerprint of the public key, a hash of its encoded bytes, in every tool and compare them.
4. Run a canary operation across tools: sign in one and verify in the others, or encapsulate in one and decapsulate in another.
5. Move production keys only after all four pass; where no seed exists for a seed-only target, schedule re-keying instead.
6. Keep the old key usable until every consumer has switched, then destroy it and record the date.

What key stores can do today

A key store is any system whose job is to hold private keys and perform operations with them so applications never see the key bytes: a cloud key management service (KMS), a hardware security module (HSM), which is a tamper-resistant device that keeps keys inside its boundary, or a secrets vault. Post-quantum support across them is uneven, and it is changing month by month, so any statement about it needs a date. The picture below was checked against vendor documentation on 25 October 2026.

Signatures arrived first. Amazon Web Services (AWS) KMS has offered ML-DSA keys at all three security levels since June 2025, generated and used inside FIPS 140-3 Level 3 hardware; it signs messages up to 4 kilobytes directly and larger ones through a pre-computed message representative, and it offers no ML-KEM or SLH-DSA key types. AWS CloudHSM generates ML-DSA key pairs, with a FIPS-mode option on its newer hardware from September 2026, but has no ML-KEM or SLH-DSA commands. Google Cloud KMS offers ML-DSA signing, SLH-DSA only in its SHA2-128s form and only at the software protection level, and a key-encapsulation purpose with ML-KEM-768, ML-KEM-1024 and a hybrid KEM called X-Wing, also at the software level. Azure Key Vault and Azure Managed HSM document no ML-KEM, ML-DSA or SLH-DSA key types at the time of checking. HashiCorp Vault's Enterprise transit engine offers ML-DSA and SLH-DSA key types marked experimental, and no KEM.

Hardware security modules moved faster on firmware than on certification. Thales released Luna firmware 7.9.0 in July 2025 with ML-KEM and ML-DSA mechanisms, and its Luna T7 module received a FIPS 140-3 certificate in July 2026 that lists both algorithms. Entrust released nShield firmware 13.8.0 in August 2025 with ML-KEM, ML-DSA and SLH-DSA, whose algorithm implementations were validated while the module certificate was still pending. Underneath them all, the PKCS#11 interface that applications use to talk to HSMs gained ML-KEM, ML-DSA and SLH-DSA mechanisms, plus brand-new encapsulate and decapsulate functions, in version 3.2, approved as an OASIS Standard in June 2026.

Keeping the key inside the boundary

The safest private key is one that never leaves the store that created it. For signatures that has long been routine: the application sends data, the store returns a signature. For key encapsulation it is new. Before PKCS#11 3.2, the standard HSM interface had a key-derivation call designed for Diffie-Hellman, but nothing shaped like encapsulate and decapsulate; vendors had to improvise. With the new functions, an application can ask an HSM to decapsulate a ciphertext and receive a handle to the resulting secret, without the decapsulation key ever being exposed.

Non-exportable keys have a cost that must be paid up front. Backups, disaster recovery and migration between vendors all need some way to move the key, usually by wrapping it, that is, encrypting it under another key that the destination also holds. Whether a store can wrap and export a post-quantum key, and in which form, seed or expanded, varies by product and is still settling. Decide the export, backup and wrapping policy for each algorithm before generating production keys, because the form and exportability chosen at generation are generally fixed for the life of the key.

A practical rule of thumb follows. Where a store supports seed export under wrapping, prefer it, because a seed is accepted everywhere the IETF formats are. Where a store keeps keys strictly non-exportable, treat the key as bound to that vendor and plan rotation, not migration, as the exit route.

Vendor migrations deserve a rehearsal. Before committing production keys, generate a throwaway key of each algorithm in the source store, export it in every form the source allows, and try to import it into the target store and into the libraries that must use it. The result is a short table, which forms each system can export and which it can import, that tells you whether the migration path exists at all. Repeat the rehearsal after firmware or service updates, because this part of the ecosystem is still moving.

Lifetimes differ by algorithm

Not every post-quantum private key needs a home at all. Most ML-KEM keys are ephemeral: a client generates a key pair for one handshake, uses it once and erases it, so the storage question never arises. Long-lived ML-KEM keys appear in designs where senders must encrypt to a recipient without a live exchange: sealed messaging, HPKE-style payload encryption, and storage systems that wrap data keys to a service's public key. Those keys need a store, a rotation period and an owner.

ML-DSA keys are typically long-lived identity keys: a service's signing key, a certificate authority's key, a release-signing key. They are where seed-versus-expanded decisions, store support and certification matter most. SLH-DSA keys are usually rare, high-value keys for roots of trust and releases that are signed seldom and verified for years, so they suit offline or tightly controlled stores even if a cloud KMS does not offer them.

Writing down a lifetime for each key class turns the store question into a short list: ephemeral KEM keys need a good random number generator and memory hygiene; long-lived KEM keys need a store that can decapsulate; signing keys need a store that can sign with the right parameter set and interface; root keys need the strongest custody you have.

Long-lived KEM keys also change how rotation works. A sender can only encapsulate to a public key it has fetched, so a rotation publishes the new encapsulation key with a validity window, keeps the old decapsulation key available for as long as ciphertexts addressed to it may still arrive, and then destroys it. Destroying the old key early strands messages; keeping it forever turns a short-lived key into a permanent liability, so the retention period belongs in the key's written record.

AI agents and the keys they must never hold

AI agents, software that plans and takes actions by calling tools, increasingly need cryptographic identities of their own: to sign requests, to prove which agent did what, or to open sealed payloads addressed to them. The tempting shortcut is to hand the agent a key file or an environment variable. With post-quantum seeds that shortcut is especially dangerous, because the seed is small enough to slip unnoticed into places that were never designed to hold secrets: a prompt, a context window, a tool result, a trace, a log line. Sixty-four bytes in an agent transcript is the entire private key.

The safer pattern is that an agent's identity is a reference to a key in a store, plus a narrowly scoped permission to use it: sign with this key, for this purpose, or decapsulate with this key, for these messages. Every use is logged by the store with the agent's identity attached. Stores that can decapsulate let an agent receive sealed payloads without ever holding the key, and stores that sign with a pre-computed message representative let an agent sign large artifacts while sending only a short value.

Decisions before the first key is generated

The decisions below are the ones practitioners and platform owners actually face. Each is cheap before the first production key exists and expensive afterwards.

1. For each key class, record the algorithm, parameter set, lifetime and owner.
2. Keep the seed, or seed and expanded key together, unless a store makes that impossible, and write down the exception.
3. Check that import paths run the hash check and a pairwise consistency test, and that the seed wins when both forms are present.
4. Confirm the target key store supports the exact algorithm, parameter set and interface, with a date and a documentation link.
5. Decide export, wrapping and backup policy per algorithm before generation.
6. Give AI agents key references and scoped permissions, never key bytes, and log every use.

Glossary

Seed

The short random value from which ML-KEM or ML-DSA key generation deterministically builds the whole key pair.

Expanded private key

The large private key computed from a seed, in the byte layout a standard defines, ready for use without recomputation.

PKCS#8

The standard container format for private keys, which the new IETF documents extend with a choice of seed, expanded key or both.

Key management service (KMS)

A managed service that holds keys and performs operations with them so applications never handle the key bytes.

Hardware security module (HSM)

A tamper-resistant device that generates, stores and uses keys inside its own protected boundary.

Key wrapping

Encrypting a key under another key so it can be exported, backed up or moved without exposure.

PKCS#11

The common programming interface applications use to ask hardware security modules to generate and use keys.

Public-key fingerprint

A hash of a public key's encoded bytes, used to confirm that two tools hold the same key.

Canary operation

A harmless test signature or encapsulation run through a real path to prove it works before real data uses it.

Further reading

1. JDK 25.0.4 Release Notes: ML-KEM and ML-DSA private key encodings (Oracle)
2. ML-DSA keys in AWS KMS (Amazon Web Services)
3. PKCS #11 Specification Version 3.2 (OASIS)
4. Keys You Did Not Generate (Research article, this site)