skip to content

Where a key manager can refuse decrypts below a chosen key version, what does raising that floor buy and what must precede it?

level: seniorimportance: should knowfreq 38%

answer

  1. a rule the manager applies to itself
  2. everything below the line fails closed
  3. backups and archives count too
  4. it is the backfill's completion test
  5. says nothing about exported material

basics

~20 s

A floor turns retirement from an intention into something the manager enforces and you can demonstrate, and it is the only completion test a backfill has. First, every copy anyone may still read - live rows, backups, replicas, archives - must already name a version at or above it.

solid answer

~50 s

A **minimum accepted version** is a declared floor on decrypt: the manager refuses any ciphertext naming a version beneath it, for every caller, regardless of grant. That buys three things. It makes retirement enforceable rather than aspirational, so you can state and show that material from before version `n` is no longer usable through the manager. It shrinks the live-version set, and therefore what must be kept, backed up and restorable. And it is the completion test a backfill otherwise lacks: raise the floor and anything you missed fails loudly instead of quietly succeeding. What must precede it is total: every ciphertext the estate can still be asked to read must already be at or above the floor - not just live storage, but backups inside the restore horizon, read replicas, exports and any archive someone might restore in three years. The floor fails closed, and it fails closed on all of them.

code

pseudocode · 9 lines
pseudocode
minAcceptedVersion = 5

function decrypt(ciphertext):
    v = ciphertext.keyVersion
    if v < minAcceptedVersion:
        refuse("names key version " + v + ", below the accepted floor")
    if not versionEnabled(v):
        refuse("names a retired key version")
    return useMaterialOf(v).decrypt(ciphertext.bytes)

go deeper

for a junior

Recall the idea: a manager can be told to stop honouring old key versions, and anything still encrypted under one of them then fails to decrypt rather than falling back to something else.

for a middle

Explain the mechanics: the floor is checked against the version each ciphertext names, applies to every caller, and fails closed. Be able to say what must be moved above the line first and why that includes copies outside live storage.

for a senior

Show the sequence you would actually run: census, rewrap or backfill, re-census, raise in a survivable window, watch refusals. Be explicit that the floor is the only loud completion test a backfill has, and that it says nothing about exported material.

for a principal

Weigh reversibility against assurance: refusing a version can be undone, destroying its material cannot, and the difference decides how much restore-horizon evidence you demand before the change. Decide what the estate is allowed to depend on, and who signs off.

## What a floor is A versioned key accumulates versions, and by default all of them stay usable for decryption. A **floor** - a minimum accepted version - is a declared rule on the manager's own decrypt path: it will not use material from any version below the stated number, whoever is asking. It is not a property of the ciphertext and not a grant on a caller; it is a constraint the manager applies to itself. Designs genuinely differ in what they offer here. Some managers let an operator name a minimum and refuse everything beneath it; some only allow individual versions to be enabled and disabled; some additionally allow the material to be destroyed. The shape of the control differs, the consequence does not: below the line, decrypts fail. ## What raising it actually buys 1. **Retirement becomes enforceable.** Before the floor, "we retired version 3" is a statement about intent. After it, it is a behaviour anyone can test by asking the manager to decrypt a version 3 ciphertext and watching it refuse. 2. **The live-version set shrinks.** Every version still in use is material that must be held, backed up, restored with the manager, and included in any statement about custody. The floor is what lets that set stop growing by one per rotation. 3. **It is a completion test.** A backfill that quietly missed a partition looks exactly like one that finished, because the missed rows keep decrypting perfectly. Raising the floor converts every miss into a loud failure. That is unpleasant, and it is the only evidence available that the campaign is done. ## What must be true first Everything the estate can still be asked to read must already sit at or above the floor: - **live storage** - the obvious part, and the part a backfill addresses; - **backups inside the restore horizon** - a restore of last quarter's snapshot brings back ciphertext at last quarter's versions; - **read replicas and exports** - copies taken while an older version was current; - **archives** - the seven-year-old partition nobody has touched since it was written, which is the one that will be requested. How expensive that is depends entirely on the shape underneath. Where each object has its own data key stored wrapped by the managed key, moving everything above the floor is a rewrap: small, per-object, and cheap. Where rows are encrypted directly under managed key versions, it is a full backfill of the corpus. The floor is the same control in both cases; the bill is not. | Before raising the floor | After raising it | |---|---| | old versions decrypt silently for anyone with a grant | those decrypts fail closed, grant or no grant | | a missed partition is invisible | a missed partition raises an error | | every version ever minted must be custodied | only versions at or above the line matter | | "retired" is a claim | retirement is observable behaviour | ## What it does not buy A floor binds the manager, not the mathematics. It says nothing about key material that already exists outside the manager: - an operator or process that exported an older version's material before the floor went up can still decrypt that ciphertext offline; - a copy of the ciphertext taken by anyone who also holds that material is unaffected; - the bytes themselves are unchanged - the floor did not re-protect them, it only stopped one system from opening them. So a floor is a control over your own estate's access path. It is genuinely useful for bounding what your systems depend on, and it is not a remedy for material that has left. ## The reversibility question, asked before the change window The last thing to establish is whether the move can be undone. Where the floor merely refuses to use versions below the line, lowering it again restores service, and a miscalculation costs an incident rather than data. Where retirement also destroys the material, there is no lowering it: anything still naming a destroyed version is unreadable permanently, including the archive discovered six months later. So the sequence a careful team runs is: census the version markers everywhere including backups and archives; rewrap or backfill whatever is below the line; re-census; raise the floor in a window when a failure is survivable; watch for refusals; and only once nothing has failed for a full restore cycle consider destroying the retired material - if at all.

  • Why is raising the floor a better completion test for a backfill than the job's own success report?
    Because a row the job skipped keeps decrypting perfectly, so nothing distinguishes a complete run from one that missed a partition. The floor removes that silence: every remaining row below the line fails on its next read. The job's report only tells you what the job believed it processed, which is exactly the thing in question.
  • A restore from a nine-month-old backup fails to decrypt after a floor was raised. Whose mistake is that?
    The change's, not the restore's. Backups inside the restore horizon are part of what must be moved above the floor before it is raised, and a nine-month backup is plainly inside most horizons. The fix is to lower the floor if the design allows it, decrypt with the old version, and re-raise it once the backup set has aged out or been re-protected.
  • Does a floor help if an older version's material was copied out of the manager last year?
    No. The floor constrains which versions the manager itself will use; it cannot affect material already held elsewhere, and whoever holds it decrypts the matching ciphertext without involving the manager at all. The floor's value is in bounding what your own systems depend on, not in undoing an export.

saying these in an interview costs you the question

  • Thinks a floor makes old ciphertext unreadable to everyone everywhere
  • Raises the floor before backfilling, then blames the backfill
  • Forgets backups and archives carry old versions
  • Treats a floor as automatic once a new version exists
  • Cannot say whether the change is reversible in their design
  • Calls a backfill complete on the job's exit code