Asymmetric encryption is credited with solving key distribution. What problem does it leave behind, and for a system that must encrypt data to many recipients, how would you decide how public keys are trusted and how long a private key may live?

## What is left behind Public-key encryption removes the need for a confidential setup channel, but it needs an authentic one. Nothing about a public key states whose it is. If an attacker substitutes theirs, you encrypt flawlessly to them and receive no error, no warning and no anomaly - the failure is silent, which is exactly why it is dangerous. The design question moves from 'how do I deliver a secret' to 'how do I know this key is theirs, and how do I stop trusting it later'. ## Four trust models and how they diverge - **Hierarchical authority.** A small set of trust anchors vouches for identities, possibly through intermediaries. It scales to strangers and provides a revocation mechanism. The cost is transitive trust: any anchor you accept can vouch for any identity, so your risk is the union of every anchor in the store, and revocation checking is itself an availability and privacy problem. - **Trust on first use with pinning.** No third party. The first key seen is remembered and a later change is loud. Strong continuity, zero protection at first contact, and painful legitimate rotation - you must plan how a key legitimately changes, or users learn to click through the warning. - **Manual verification of fingerprints out of band.** The strongest binding available and the least scalable; realistic for a handful of high-value peers, not a user base. - **Transparency logs.** Append-only public records of issued keys turn an undetectable mis-issuance into a detectable one. That is a different security goal - detection rather than prevention - and it is what makes a hierarchy tolerable at internet scale. Real systems blend them: an authority for scale, pinning for the highest-value peers, and a log so mis-issuance leaves evidence. ## Blast radius drives lifetime A static key pair used to wrap data keys has no forward secrecy: an attacker who records ciphertext for years and eventually obtains the private key decrypts all of it retroactively. Bound that: 1. **Ephemeral key agreement per session** for data in motion, so a later key compromise does not open recorded traffic. 2. **A key hierarchy** - a master key wraps intermediate keys, which wrap per-object data keys - so rotating the top is a rewrap of small keys rather than re-encrypting the corpus. This is what makes a short lifetime affordable. 3. **Non-extractable private keys** in a hardware module or dedicated service, so a host compromise becomes use-only: the attacker can decrypt while they hold access, but cannot walk away with the key or use it after eviction. That converts an unbounded retroactive loss into a bounded, rate-limited and auditable one. 4. **A key identifier in every envelope.** Rotation without an inventory of which key protected which object is a fiction; you cannot rewrap, cannot revoke, and cannot answer what a leaked key exposes. ## The decision inputs Set the secrecy horizon first: how long must this plaintext stay confidential. That is the floor on cryptographic margin and the ceiling on acceptable retroactive exposure. Then ask how fast you could re-key the corpus if you had to, whether compromise would be detectable at all, how often recipients join and leave, and who must be able to decrypt in a disaster. That last one is a genuine tension: losing the private key destroys the data, so availability and escrow are security requirements too, and every escrow copy is another place the key can leak. Decide it explicitly rather than discovering it during an incident. ## The honest limit Removing a recipient is not retroactive. Anyone who already unwrapped a data key keeps it forever, so 'revoking access' means re-encrypting under a new key going forward. Say this out loud in a design review, because product owners routinely assume otherwise.