how to eliminate stored private keys
How to eliminate stored private keys: a practitioner's guide
Every breach of a key-management system is a breach of something stored. The honest engineering question is whether the key needs to exist between operations at all. For most signing, decryption, and authentication workloads it does not, the key only needs to exist at the moment of use. This article maps the four conventional storage models, the failure mode each one accepts, and a fifth model that holds no key material at rest.
By Sue Pontius, Chief Executive Officer, Lokblok · Published 22 April 2026
The four conventional storage models
Hardware security modules (HSMs) keep keys inside a tamper-resistant boundary. The boundary is excellent; the assumption that a key must live inside it for years is the weak point. Every HSM-protected key is a multi-year target with a known location.
MPC shares distribute the key across operators so no single party holds it whole. Effective against single-operator compromise; ineffective against share-store breaches, insider collusion, or the brief recombination window during signing.
Encrypted backups (cold storage, KMS-wrapped blobs, paper backups) push the problem to a key-encryption key. The KEK is itself a key that must be stored somewhere, usually with weaker controls than the keys it protects.
Seed phrases and BIP39 mnemonics are the retail equivalent: a written secret with the same lifetime as the wallet. They fail at recovery time, when the user must produce a piece of paper that may have been lost, photographed, or coerced.
A fifth model: hold no key, reconstruct on demand
Zero-persistence key reconstruction stores only public, non-sensitive Regen Tokens between operations. When a signing or decryption call arrives, a quorum of independent recovery agents authorises the operation; ephemeral shares are derived inside a certified secure element; the key is reconstructed for that single operation and destroyed before the call returns. The attack surface at rest is not 'small', it is empty.
Recovery uses the same primitive: a quorum re-derives the key on demand, with no special ceremony and no temporary assembly point. The disaster-recovery flow stops being a separate, weaker security regime than everyday operation.
Side by side
| Dimension | Conventional approach | Zero-persistence reconstruction |
|---|---|---|
| Key at rest | Encrypted blob, sharded blob, or written phrase | None, only public Regen Tokens |
| Theft surface | Persistent, measured in years | Ephemeral, measured in milliseconds |
| Insider access | Privileged operators can read or assemble | Operators have nothing useful to read |
| Backup | Separate, often weaker, copies | Same flow as signing, no copies needed |
| Recovery | Custodian / seed-phrase ceremony | Quorum re-derives on demand |
| Audit | Process and log review | Hardware-attested cryptographic chain |
What this looks like in practice
- A SaaS platform that signs customer artefacts stops budgeting for an HSM cluster's lifetime threat model, the per-tenant signing key only exists for the milliseconds it is used.
- A retail wallet vendor removes the seed-phrase recovery flow and replaces it with a quorum of devices the user already controls plus a recovery-agent network.
- A regulated bank running internal PKI ages out long-lived KMS-wrapped keys in favour of per-operation ephemeral keys, shrinking the cryptographic-incident blast radius from 'all signatures since rotation' to 'one signature'.
Related Lokblok material
- zero standing secrets as an architectural principle
- hardware-rooted threshold reconstruction
- Phantom Secrets™ as a key-management protocol
About the author
Sue Pontius
Chief Executive Officer, Lokblok
Sue Pontius is CEO of Lokblok, where she leads the company's work on zero-persistence cryptography for digital assets, identity, and high-assurance custody.
View LinkedIn profile →FAQ
- Doesn't every system need a key somewhere?
- Every system needs a key at the instant of use. It does not need a key between uses. Zero-persistence reconstruction stores only public material at rest and assembles a key inside hardware only when an authorised operation is in flight, then destroys it immediately.
- How does this differ from short-lived KMS-wrapped keys?
- Short-lived keys are still stored, the wrapping key is the persistent secret. Zero-persistence reconstruction has no persistent secret at any layer; the artifacts at rest are public Regen Tokens that cannot reproduce a key on their own, regardless of who reads them.
- Can the same model protect symmetric encryption keys, not just signing keys?
- Yes. The same threshold-reconstruction primitive applies to any cryptographic operation that needs a key briefly: AES data-encryption keys, JWT-signing keys, code-signing keys, and TLS server keys can all be reconstructed on demand inside hardware without persistent storage.
- What about latency?
- Reconstruction adds the network round-trip to the recovery agents and the secure-element operation. For most signing and decryption workloads this is in the low tens of milliseconds, comparable to a remote KMS call and lower than many HSM cluster operations.