Key Management
Cryptography is only as strong as the handling of its keys, so generating, storing, rotating, and retiring them safely is the hard part.
The Real Difficulty in Cryptography
Algorithms like AES and RSA are well studied and hard to break directly. Real systems fail at key management: keys stored in plaintext, hard-coded in source code, shared over email, never rotated, or never revoked after an employee leaves. A perfect cipher protects nothing if its key is easy to steal. Managing keys across their full lifecycle is where most cryptographic security is won or lost.
The Key Lifecycle
- Generation: from a strong random source, with sufficient length
- Distribution: to authorized parties without exposure
- Storage: protected, ideally in dedicated hardware
- Rotation: replaced periodically to limit exposure
- Revocation: invalidated promptly when compromised
- Destruction: securely erased at end of life
Separation and Least Privilege
Keys should be stored separately from the data they protect and accessible only to the components that genuinely need them. Access to keys is logged and controlled independently. Dedicated key-management services and hardware security modules keep keys in tamper-resistant hardware so that even a compromised application can request cryptographic operations without ever extracting the key itself.
Rotation and Blast Radius
Regular rotation limits how much data a single compromised key exposes. Envelope encryption, where data keys are themselves encrypted by a master key, lets you rotate the master without re-encrypting everything, shrinking the operational burden of good hygiene.
Fusion Context
A fusion program's signing keys for firmware and its encryption keys for design data are high-value targets. The Hyperion breeder and burner security designs specify hardware-backed key storage, strict separation between keys and data, and rotation and revocation procedures, with post-quantum migration considered given the decades-long lifetime of the plant.