Overview

Algorithms rarely fail; key management fails constantly. Ed25519 and AES are effectively unbreakable, but a private key committed to a public repo, baked into a container image, or emailed to a contractor breaks everything instantly and silently. In real systems the whole game is keeping keys secret, available, and under control across their entire life.

Where keys actually live and how they leak

A key exists somewhere at every moment: in memory while used, on disk at rest, in transit while distributed. Each location is a chance to leak. The most common real-world leaks are mundane:

Leak vector	Example	Fix
Hardcoded in source	API_KEY = "sk-live-..."	Move to a secret store; scan the repo
Committed to Git history	Key deleted but still in an old commit	Rotate immediately; history purge is not enough
Container image layers	COPY key.pem in a Dockerfile	Mount secrets at runtime instead
Logs and error dumps	Key printed in a stack trace	Redact; never log key material
Overbroad access	Whole team can read prod keys	Least privilege via IAM

The uncomfortable truth: once a key is exposed you must treat it as compromised and rotate it, even if you are not sure anyone saw it. The sibling page Key Generation & Storage covers the leak hierarchy in detail, from hardcoded strings up to hardware modules.

The key lifecycle

Think of a key as having stages, each with its own risks:

1. Generate with a strong RNG and correct parameters (see Key Generation & Storage).
2. Store encrypted at rest with strict access control.
3. Distribute only what is needed, only to who needs it.
4. Use ideally without ever exposing the raw key (see KMS & HSM).
5. Rotate on a schedule and on any suspected exposure (see Key Rotation).
6. Retire and destroy old keys so they cannot be misused later.

Rotation without downtime

The naive fear is that rotating a key breaks everything signed or encrypted with the old one. The industry answer is versioning: give every key a version identifier, keep the old version available for reads and verification while the new version handles new writes and signatures, then retire the old version once nothing depends on it. This dual-read window makes rotation a routine, zero-downtime operation rather than an outage. The sibling Key Rotation page works through the patterns, including envelope encryption that lets you rotate a key without re-encrypting your data.

HSMs and cloud KMS services

The strongest protection is to make the raw key impossible to extract. A Hardware Security Module (HSM) generates and holds keys inside tamper-resistant hardware and only performs operations (sign, decrypt) on request, never handing the key back. A cloud KMS (AWS KMS, GCP Cloud KMS, Azure Key Vault) offers the same use-but-never-extract property as a managed service, where your real security perimeter becomes IAM policy rather than file permissions. The sibling KMS & HSM page explains the mental model and when each is warranted.

Practical Guidance

1. Treat key management, not algorithm choice, as your primary crypto risk. Strong algorithms with leaked keys buy you nothing.
2. Never hardcode keys in source or bake them into images. Keep them in a secret store or KMS and inject at runtime.
3. Scan repos and CI for accidental key commits, and assume any exposed key is compromised: rotate it.
4. Version every key so rotation is a dual-read operation with no downtime.
5. Push toward use-but-never-extract: prefer KMS or HSM over raw key files for anything valuable.
6. Enforce least privilege on key access and audit who can use each key.