skip to content

A new key version changes the algorithm as well as the key material - what must every reader still be able to do?

level: middleimportance: nice to knowfreq 24%

answer

  1. the version binds more than material
  2. no global algorithm setting
  3. the marker routes both choices
  4. readers deploy before writers
  5. only a backfill moves old rows

basics

~20 s

Readers must resolve the algorithm from the version the ciphertext names, not from a global setting. A version binds material and algorithm together, so one corpus can legitimately hold rows produced several different ways at once.

solid answer

~50 s

A key version is not only key material; in many designs it also fixes the algorithm and its parameters. When a new version changes both, existing rows keep decrypting exactly as before - under their own version, with its own algorithm - and new writes use the new one. That forces one property on every reader: the algorithm must be selected per ciphertext, from the version marker, never from a single configuration value meaning *the algorithm we use*. It also orders the rollout: every reader has to understand the new construction **before** the write side starts producing it, or the first row written under the new version is unreadable by half the estate. And it changes what the rotation is worth - if the point of the change was that the old construction is no longer adequate, only a backfill moves stored data forward.

go deeper

for a junior

Recall that a key version can decide how a value was encrypted, not just with which bytes, so two rows in the same table may have been produced in genuinely different ways and both are valid.

for a middle

Explain the consequence: the decrypt path takes its algorithm from the version marker, never from a global setting, and the corpus legitimately holds several constructions at once for as long as retention lasts.

for a senior

Show the rollout order and why it is that order: readers everywhere first, then the write pointer, then the backfill driven by markers, then a census, then the floor. Name what breaks if each step is skipped.

for a principal

Judge whether the corpus must move at all. A key change can be left un-backfilled deliberately; a construction change usually cannot, because the stored data is the reason for it - so budget the campaign when you approve the change, not afterwards.

## A version binds more than material It is tempting to read a key version as *the same algorithm, different bytes*. In many designs it is more than that: a version fixes the key material **and** the construction used with it, including parameter sizes and any per-record overhead. Minting a new version can therefore change how a value is encrypted, not merely what key encrypted it. That is a deliberately useful property. Moving a corpus to a better construction is otherwise a schema migration; expressed as a key version it rides the machinery that already exists - a marker per ciphertext, a pointer for new writes, a floor for retirement. ## What the reader must do One rule carries all of it: **resolve the algorithm from the version the ciphertext names.** The decrypt path is parameterised by the marker, exactly as key selection is: - the reader passes the stored bytes and their version; - the manager looks up that version's material *and* its construction; - it decrypts the way that version was written. The pattern this outlaws is a single setting - in code or configuration - that names *the* algorithm. Such a setting cannot be right for a corpus that holds rows written under two versions, which is every corpus from the moment the second version exists. ## What that constrains - **No global algorithm switch.** If the choice lives anywhere but the version, a deployment can silently start decrypting the wrong way. - **No pinned sizes.** Output length and per-record overhead can differ between constructions, so a fixed-width column, a length assumption in a parser, or a buffer sized for the old output will reject the new one. - **No fixed-offset parsing.** Anything that reaches into a stored blob by byte offset is reading a layout that a version change is allowed to move. - **Readers before writers.** Every process that may read new data must understand the new construction before the current-version pointer moves. Deploy readers first, then move the write pointer; the reverse produces rows nobody can open. - **Mixed corpus is the normal state,** not a transitional glitch. The estate will hold several constructions simultaneously for as long as retention lasts. ## Why the migration is still a backfill This is the honest part, and it separates an algorithm change from an ordinary key change. | Change | Stored rows after the rotation | Is leaving them acceptable? | |---|---|---| | new key material, same construction | still fine, protected by the earlier version | usually yes - the old material is still sound | | new construction, because the old one is no longer adequate | still written the old way | usually no - the reason for the change applies to them | Minting a version changes the write path. It does nothing to a row written last year, which keeps its marker, its material and its construction until something rewrites it. So where a key change can often be left un-backfilled as a deliberate, defensible decision, an algorithm change usually cannot: the corpus is the reason you are changing, and only a rewrite moves the corpus. That is also where the floor earns its place. Once every row has been rewritten, raising the minimum accepted version turns *we believe the old construction is gone* into a behaviour that fails loudly if any row was missed. Without it, a missed partition simply keeps decrypting the old way forever, silently, which is the exact outcome the change was meant to end. ## The order to state out loud 1. Roll out readers that understand the new construction everywhere, including batch jobs, restore tooling and anything that reads archives. 2. Move the current-version pointer so new writes use the new version. 3. Backfill the existing corpus, driven by each row's own version marker so the job is idempotent. 4. Census the markers across live storage, backups and archives. 5. Raise the floor, and let anything missed fail loudly. Skip step 1 and the first new row breaks a reader. Skip step 3 and the change achieved nothing for the data that motivated it. Skip step 5 and you will never know whether step 3 finished.

  • Why must readers understand the new construction before the write pointer moves?
    Because the first row written under the new version is immediately readable only by processes that know how. Move the pointer first and every lagging reader - a batch job, a restore tool, an archive scanner - hits data it cannot open, and the failure appears in whichever component was deployed last rather than where the change was made.
  • What storage assumptions break when a version changes the construction rather than just the key?
    Anything that pinned a size or a layout: a fixed-width column sized for the old output, a buffer or parser expecting a particular per-record overhead, and any code reaching into the stored blob by byte offset. The version marker must be the only thing read positionally; everything past it belongs to the version.

saying these in an interview costs you the question

  • Selects the algorithm from configuration rather than the ciphertext's version
  • Assumes all stored rows share one construction
  • Thinks minting the version upgrades existing rows
  • Moves the write pointer before readers are deployed
  • Pins column widths or offsets to the old output size