skip to content

When the key protecting a large archive is rotated, what is actually re-encrypted and what is left alone?

level: seniorimportance: nice to knowfreq 30%

answer

  1. cheap because the bytes stay put
  2. new version, same objects
  3. old ciphertext needs the old version
  4. rotation is not revocation
  5. re-encryption priced by data volume

basics

~20 s

Normally nothing in the archive is re-encrypted. Rotation adds a new key version that future wraps use; existing objects keep the version they were written under, which is why rotation is cheap and why it is not revocation.

solid answer

~40 s

Under envelope encryption, rotating the wrapping key creates a new version that new wraps use, while each stored object keeps a reference to the version its data key was wrapped under. The object bytes are untouched, so rotation of a multi-terabyte archive costs almost nothing - and old versions are retained for decryption, so reads never break. The consequence people miss is that rotation therefore limits nothing about what a later revocation can reach: yesterday's ciphertext stays readable until the old versions are actually destroyed, which is a separate act. Full re-encryption - rewriting every object under the new key - is the expensive operation, priced by data volume and by the store's write path, and it is needed only for a real custody change or a suspected key compromise.

code

pseudocode · 11 lines
pseudocode
on rotate(keyId):
    keyService.addVersion(keyId)      # the new version is used for future wraps
    # no object is read, rewritten or re-encrypted here

on read(objectId):
    record  = store.get(objectId)
    version = record.metadata.keyVersion      # often an older version
    dataKey = keyService.unwrap(record.metadata.wrappedKey, record.metadata.keyId, version)
    if version is destroyed:
        return error("object unreadable")     # only destruction, never rotation, lands here
    return decrypt(record.ciphertext, dataKey)

go deeper

for a junior

Remember the shape: rotating a key makes a new version for future use and leaves existing data as it is. Nothing becomes unreadable when a key is rotated.

for a middle

Explain why rotation is cheap - only the small wrapped data key is involved - and why each object records the key version it used, so reads keep working against retained older versions.

for a senior

Separate rotation, version retirement and destruction, and say which one actually changes readability. Be able to price a full re-encryption as a data migration, including retained versions left behind on a versioned store.

for a principal

Decide the policy: rotation cadence, whether old versions are retained forever or retired, and when a re-encryption is worth its cost. Note that key scope, not cadence, is what a future destruction obligation will depend on.

## Rotation under envelope encryption Because the bytes are encrypted under a per-object **data key** and only that small data key is wrapped under the long-lived key, rotating the long-lived key is an operation on key material, not on data. A rotation typically: 1. creates a **new version** of the key, which becomes the version used for future `wrap` calls; 2. leaves earlier versions in place, usable for `unwrap` only; 3. touches nothing in the store - no object is read, rewritten or re-encrypted. Each stored object carries, in its metadata, which key and which version its data key was wrapped under, so a read simply asks for that version. This is why rotation scales: an archive of any size rotates in the time it takes to create one key version. ## What rotation changes, and what it does not - **It changes** how much data a single key version protects going forward, which is the actual security argument for rotating on a clock. - **It changes** nothing about existing ciphertext, which stays wrapped under the older version. - **It does not** make yesterday's data unreadable, because the older versions are retained precisely so reads keep working. - **It does not** satisfy a destruction obligation. That needs a version or a key to be destroyed, which is a different operation with a different blast radius. - **It does not** move data onto a different key you control. Changing custody is a re-encryption problem, not a rotation problem. ## Rotation against full re-encryption | | Rotation | Full re-encryption | |---|---|---| | What is touched | one key version | every object, read and rewritten | | Cost | effectively flat, whatever the archive size | scales with data volume and the store's write path | | Effect on old ciphertext | none, it stays readable under the old version | it is replaced by ciphertext under the new key | | What it is for | limiting a version's exposure, satisfying a policy clock | a suspected compromise, or a genuine custody change | | Side effects | none worth naming | new object versions, lifecycle and retention effects, a large write bill | Re-encryption also interacts badly with a store that keeps versions: rewriting an object can leave the previous ciphertext behind as a retained version, still wrapped under the old key, which quietly defeats the point unless those versions are removed too. ## The trap worth naming The common mistake is treating a rotation schedule as if it limited a later revocation's reach, as though old data aged out from under the key. It does not. Three claims must be kept apart, and they fail differently: - **Rotation** bounds how much new data one key version protects. - **Retiring a version** stops it being used for new wraps but keeps it able to decrypt. - **Destroying a version or key** is what makes ciphertext unopenable - and only for ciphertext that still depends on it. Designs differ on the middle step: some platforms rotate automatically on a schedule and retain every prior version indefinitely for decrypt, while others expose explicit version retirement and destruction. Whichever you have, the readability of old data follows the last step, never the first. ## When re-encryption is genuinely required Reach for the expensive operation in a small number of cases: when a key version is believed compromised and old ciphertext must stop depending on it; when custody itself is changing, because many services apply a changed key only to new writes so the existing archive has to be rewritten to move under it; and when key scope is being narrowed - for example splitting a single archive key into one key per customer so that a later destruction request has a switch that matches it. Plan it as a data migration with a cost proportional to the archive, not as a key-service setting.

  • If rotation does not re-encrypt anything, what is the security argument for doing it?
    It bounds how much data any single key version has ever protected, so the consequence of one version being compromised is limited to the window it was current for. It also gives you a working rotation path to exercise, so that an emergency rotation is a routine operation rather than a first attempt under pressure.
  • What makes re-encrypting a large archive expensive beyond the compute?
    It is a full read and rewrite priced by data volume, so it touches the store's write path, any retrieval charges on colder data, and replication of every rewritten object. On a versioned store it can also leave the old ciphertext behind as a retained version, which has to be removed separately or the exercise achieves nothing.

saying these in an interview costs you the question

  • Says rotating the key re-encrypts every stored object.
  • Treats a rotation schedule as a way to make older data unreadable.
  • Assumes older key versions are destroyed as soon as a new one exists.
  • Prices re-encryption as free because the store does it in the background.
  • Believes a rotation policy alone satisfies a destroy-on-request obligation.