A key that encrypts stored records leaked in a contractor's backup — what does minting a new key version protect, and what is already lost?
answer
- forward-looking, not retroactive
- two things were taken, not one
- new writes versus existing ciphertext
- re-encrypt only what you still control
- retirement stops your own reads
basics
~20 sMinting a new key version protects only data encrypted after the change. Anything the leaked version already encrypted stays readable to whoever holds it, along with any ciphertext copy they took, so rotation bounds future exposure and never past exposure.
solid answer
~40 sA new key version changes which key encrypts new writes; it changes nothing about ciphertext that already exists. If whoever took the key also took a copy of the encrypted records, those records stay decryptable to them forever — no later version reaches a copy you do not control. Re-encrypting the data you still hold under the new key is what re-protects those copies, and retiring the old version is what stops your own systems reading anything with the leaked material. So minting buys two things: new writes protected by material the holder does not have, and a path to retirement. It does not buy recovery. Report the exposure as the set of records that key covered, not as fixed by rotation.
go deeper
Recall that a key version decides what encrypts new writes. Records written earlier stay tied to the version that wrote them, so a new version changes nothing about data already on disk.
Explain the mechanics: ciphertext records which version produced it, a read resolves that version rather than the newest one, and only a separate re-encryption pass moves data onto the new key.
Separate what you control from what you do not. Re-encryption protects your own copies, including backups and exports; any copy already taken is permanently disclosed, and the response should be driven off the data the key covered.
Own the reporting line. Rotation is a containment step, not a remedy, and the disclosure estimate is the set of records the exposed key protected. Decide what you tell stakeholders before the re-encryption finishes, not after.
## What a key version actually changes A **key version** is one generation of key material inside a key manager. When something asks the manager to encrypt, it uses the version currently marked as the encrypting one, and hands back ciphertext that normally carries an identifier — call it `keyVersion` — so a later read can find the right material again. Designs differ in where that identifier lives and whether it exists at all, but the model is the same everywhere. Minting a new version changes exactly one thing on its own: which version the manager reaches for the next time something asks it to encrypt. Nothing walks the stored data. Every record already written still carries the old `keyVersion` and is still bound to the old material. That is why "we rotated the key" is not an answer to "what did the leak cost us" — rotation is a statement about the future, and the question is about the past. ## The holder has two separate things After key material escapes, work out which of two situations you are in, because the remedy differs: - **The key material alone.** The holder can decrypt anything encrypted under it *that they can also obtain*. The scope is whatever ciphertext they can still reach — live systems, backups, an old export. - **The key material and a copy of the ciphertext.** The confidentiality of that copy is gone permanently. Nothing available to you touches bytes sitting on somebody else's disk. The second case is the one that makes people uncomfortable, and it is the honest default assumption when a key file turns up somewhere it was never meant to be: whoever bothered to keep the key usually kept something to use it on. | What you do | What it fixes | What it does not fix | |---|---|---| | Mint a new version | New writes use material the holder does not have | Anything already written | | Re-encrypt stored data | Copies you control stop opening with the old key | Copies already taken | | Retire the old version | Your own systems can no longer read with it | The holder's copy, which never used your systems | | Destroy the old material | Old ciphertext stops opening for anyone without the key | The holder, who has the key | ## Why the new version cannot reach the past Ciphertext is inert. It is not a live object that consults the manager for the current key; it is bytes that were produced once, under one key, and that only that key opens. A read resolves whichever version the record names, which is exactly why data written years ago still reads correctly after many rotations — and exactly why a rotation cannot retroactively protect it. Moving existing data onto the new key is therefore a **separate job**: read every record with the old key, write it back under the new one. It costs a full pass over the data, it takes real time on a large set, and on a big estate it is scheduled work rather than an incident action. Some managers offer to run that pass for you and some do not; the cost is the same either way, because the bytes have to be rewritten. ## The order the work runs in 1. **Mint** the replacement and point new writes at it. Cheap, immediate, and it stops the exposed set from growing. 2. **Re-encrypt** the copies you still control — and remember that backups, replicas and exports are copies you control too. 3. **Retire** the old version once nothing still needs it, so your own systems stop being able to read with leaked material. Note what is missing from that list: a step that recovers what was taken. There is none. ## Where this goes wrong in practice - An incident note that reads "key rotated, closed", with no statement of what the old key covered. - A disclosure estimate scoped to the data written *after* the leak was discovered, rather than everything the key ever encrypted. - Assuming the old version stopped working the moment the new one appeared. On most designs the earlier version keeps decrypting until it is explicitly disabled or destroyed — which is deliberate, since otherwise every rotation would be an outage. - Confusing **minting** with **retiring**. They are two actions, and only the second one closes anything, and only inside your own estate. - Treating re-encryption as the remedy for the leak rather than as hygiene for your own copies. ## What to say when asked Say that the new version bounds future exposure, that the old ciphertext is unchanged and still opens with the leaked material, that re-encryption helps only the copies you still control, and that the size of the incident is the set of records the exposed key protected — which is a scoping question, not a rotation question.
- Does destroying the leaked key version make the old ciphertext safe?It makes that ciphertext unreadable to anyone holding only the ciphertext — including you — but it does nothing to whoever already has the key material. Destruction closes your own estate's ability to read old data; it does not recall what was taken, and it turns any record you failed to migrate into permanent data loss.
- How do you decide whether re-encrypting the historical data is worth the effort?Weigh what it buys against what it costs. It buys one thing: the copies you still control stop opening with the leaked key. Where the holder plainly took the data as well as the key, re-encryption changes nothing for them, and the effort belongs on bounding what was taken and on the copies still inside your estate — backups and exports first, since they are the ones that outlive everything.
Changing the lock on the filing cabinet does not un-photocopy the pages somebody already carried out of the building.
saying these in an interview costs you the question
- Says rotating the key fixed the leak
- Assumes old ciphertext becomes unreadable once a new version exists
- Forgets the holder may have taken ciphertext copies too
- Treats minting a new version as retiring the old one
- Scopes the disclosure to data written after discovery