eduKateSG · Information · The Gold Standard of Education
Rotate the wrapping layer without assuming old ciphertext has magically changed
Choose the explanation you need, or follow all twelve chapters in order.
Full chapter index · Independent practice · Information subject guide
Envelope encryption separates bulk-data encryption from long-lived key management. A data encryption key protects the plaintext; a wrapping key protects that data key. The encrypted data key travels with the ciphertext and metadata needed to recover it. This separation can make rotation and access control manageable, but only if the system distinguishes rotating wrapping-key material, rewrapping encrypted data keys and re-encrypting the underlying data.
The examples are architecture teaching examples, not deployment instructions. Production cryptography should use reviewed libraries, protected key services, authenticated encryption, tested recovery and organisation-specific security requirements.
The practical goal is controlled change with recoverability. A rotation plan should identify the cryptographic layer being changed, the records that must be rewritten, the old dependencies that remain, the rollback point, and the evidence required before retirement. Without that map, a team can truthfully report that a key rotated while leaving historical objects dependent on the previous protection path.
Use test objects that represent current, old, archived and partially migrated states. Rehearse encryption, ordinary decryption, migration retry, rollback, backup restoration and final key retirement in an isolated environment. Confirm that audit events identify the logical object and key version without exposing sensitive material. These exercises turn a paper key lifecycle into evidence that the application, metadata store, key service and recovery team agree on the same envelope contract.
Continue from The Gold Standard of Information within The Gold Standard of Education: learning that transfers into life and the How X Works learning library.
Full chapter index
See the mechanism · Chapters 1–2
Build the worked model · Chapters 3–5
Test what changes · Chapters 6–8
Check evidence and limits · Chapters 9–10
Practise and continue · Chapters 11–12
The plaintext is encrypted with a data encryption key, producing ciphertext and an authentication tag. The data key is then encrypted or wrapped under a key-encryption key. Store the encrypted data key, algorithm identifiers, nonce or IV, authentication data and context needed for decryption.
Avoid calling every key a “master key.” Name roles: data key, wrapping key, key identifier and protected key material. Roles determine which operation is safe and which record must change.
The plaintext data key should exist only where needed and for as short a time as the library and platform allow. Do not log it, serialize it into application traces or place it in an ordinary cache.
Evidence check: for Draw the envelope before naming the keys, preserve the observation before the interpretation. Record the exact erasure unit and tolerated failure domain. Then state the inference, one credible alternative, and the additional observation that would distinguish them. This compact audit keeps a fluent explanation tied to evidence that another reader can inspect.
Changed-context transfer: repeat this chapter’s decision after changing one consequential condition while holding the others fixed. Calculate or predict what should change, name the threshold or mechanism, and compare with the original case. If the conclusion survives, state the range tested; if it reverses, explain why. Transfer is demonstrated by the changed case, not asserted from the first example.
Practical decision record: write one sentence for what is known, one for what remains uncertain, and one for the next safe action. Include the evidence owner, the latest useful decision time, and the condition that would stop or reverse the action. This turns a technical result into a reviewable choice without pretending uncertainty has disappeared.
CHAPTER 2 OF 12 · See the mechanism
2. Follow encryption and decryption as two explicit flows
For encryption, generate a fresh data key, encrypt the data, wrap the data key, then discard the plaintext data-key copy after use. For decryption, authenticate the request and context, unwrap the encrypted data key, decrypt and verify the ciphertext, then release plaintext only after integrity succeeds.
Order matters. Returning unauthenticated plaintext before tag verification can expose altered data. Treat algorithm and context fields as part of the authenticated contract rather than hints.
Log key identifiers, operation results and authorization decisions without logging plaintext keys or sensitive data. The audit should explain which protected key handled which object.
Evidence check: for Follow encryption and decryption as two explicit flows, preserve the observation before the interpretation. Record k, m, shard order and coding profile. Then state the inference, one credible alternative, and the additional observation that would distinguish them. This compact audit keeps a fluent explanation tied to evidence that another reader can inspect.
Changed-context transfer: repeat this chapter’s decision after changing one consequential condition while holding the others fixed. Calculate or predict what should change, name the threshold or mechanism, and compare with the original case. If the conclusion survives, state the range tested; if it reverses, explain why. Transfer is demonstrated by the changed case, not asserted from the first example.
Practical decision record: write one sentence for what is known, one for what remains uncertain, and one for the next safe action. Include the evidence owner, the latest useful decision time, and the condition that would stop or reverse the action. This turns a technical result into a reviewable choice without pretending uncertainty has disappeared.
Imagine object O-174 uses data key D-174. The object record stores ciphertext C-174, nonce N-174, tag T-174, encrypted data key EDK-174, wrapping-key identifier K-2026-01, algorithm suite A1 and encryption context {tenant:42, object:O-174}.
The encrypted data key is not the same as the data key. It may be safe to store alongside ciphertext under the threat model because the wrapping key remains protected. That assumption must include authorization and service compromise boundaries.
Changing the wrapping-key identifier alone does nothing. EDK-174 must actually be produced under the new wrapping key, or the metadata will point to a key that cannot recover it.
Evidence check: for A small envelope record, preserve the observation before the interpretation. Record which position is missing and which values remain valid. Then state the inference, one credible alternative, and the additional observation that would distinguish them. This compact audit keeps a fluent explanation tied to evidence that another reader can inspect.
Changed-context transfer: repeat this chapter’s decision after changing one consequential condition while holding the others fixed. Calculate or predict what should change, name the threshold or mechanism, and compare with the original case. If the conclusion survives, state the range tested; if it reverses, explain why. Transfer is demonstrated by the changed case, not asserted from the first example.
Practical decision record: write one sentence for what is known, one for what remains uncertain, and one for the next safe action. Include the evidence owner, the latest useful decision time, and the condition that would stop or reverse the action. This turns a technical result into a reviewable choice without pretending uncertainty has disappeared.
First, future-use rotation changes which wrapping key protects newly generated data keys. Existing ciphertext and encrypted data keys remain as they were and still depend on the old key.
Second, rewrapping decrypts or re-encrypts the encrypted data key under a new wrapping key while leaving the bulk ciphertext unchanged. This is often much cheaper than reading and encrypting the whole object.
Third, full data re-encryption decrypts the object and encrypts it with a new data key, nonce and ciphertext. This changes the data-protection layer and carries more operational exposure, bandwidth and failure modes.
| Operation | New writes | Existing encrypted data key | Bulk ciphertext |
|---|---|---|---|
| Future-use rotation | Use new wrapper | Unchanged | Unchanged |
| Rewrap data key | Use new wrapper | Replaced | Unchanged |
| Full re-encryption | Use new wrapper/data key | Replaced | Replaced |
Evidence check: for Rotation has three different meanings, preserve the observation before the interpretation. Record survivor count and independence of repair equations. Then state the inference, one credible alternative, and the additional observation that would distinguish them. This compact audit keeps a fluent explanation tied to evidence that another reader can inspect.
Changed-context transfer: repeat this chapter’s decision after changing one consequential condition while holding the others fixed. Calculate or predict what should change, name the threshold or mechanism, and compare with the original case. If the conclusion survives, state the range tested; if it reverses, explain why. Transfer is demonstrated by the changed case, not asserted from the first example.
Practical decision record: write one sentence for what is known, one for what remains uncertain, and one for the next safe action. Include the evidence owner, the latest useful decision time, and the condition that would stop or reverse the action. This turns a technical result into a reviewable choice without pretending uncertainty has disappeared.
Suppose one million objects use wrapping key K-old. A migration creates K-new and immediately directs new writes to it. A background job selects each object, asks the key service to transform its encrypted data key, writes the new EDK and key identifier atomically, and verifies a sample through decryption.
The object ciphertext does not change. The job needs idempotency: retrying object O-174 must recognise whether its EDK is already under K-new. A migration-state field or verified key identifier prevents double wrapping.
Keep K-old enabled until inventory shows no required object depends on it and recovery tests pass. Disabling first turns an orderly migration into an outage.
Evidence check: for A worked rewrapping migration, preserve the observation before the interpretation. Record field, matrix, padding and interoperability tests. Then state the inference, one credible alternative, and the additional observation that would distinguish them. This compact audit keeps a fluent explanation tied to evidence that another reader can inspect.
Changed-context transfer: repeat this chapter’s decision after changing one consequential condition while holding the others fixed. Calculate or predict what should change, name the threshold or mechanism, and compare with the original case. If the conclusion survives, state the range tested; if it reverses, explain why. Transfer is demonstrated by the changed case, not asserted from the first example.
Practical decision record: write one sentence for what is known, one for what remains uncertain, and one for the next safe action. Include the evidence owner, the latest useful decision time, and the condition that would stop or reverse the action. This turns a technical result into a reviewable choice without pretending uncertainty has disappeared.
CHAPTER 6 OF 12 · Test what changes
6. Automatic key-material rotation has a boundary
Some managed key services rotate backing key material while keeping the logical key identifier stable. New operations use new material, while the service retains older material to decrypt earlier ciphertext.
That operation does not necessarily rotate data keys or rewrite application objects. It can satisfy one key-material policy without satisfying a requirement to move data away from a compromised authorization boundary.
Read the service’s exact semantics. “Rotation enabled” is not evidence that every historical encrypted data key was rewrapped.
Evidence check: for Automatic key-material rotation has a boundary, preserve the observation before the interpretation. Record source-block and symbol identifiers. Then state the inference, one credible alternative, and the additional observation that would distinguish them. This compact audit keeps a fluent explanation tied to evidence that another reader can inspect.
Changed-context transfer: repeat this chapter’s decision after changing one consequential condition while holding the others fixed. Calculate or predict what should change, name the threshold or mechanism, and compare with the original case. If the conclusion survives, state the range tested; if it reverses, explain why. Transfer is demonstrated by the changed case, not asserted from the first example.
Practical decision record: write one sentence for what is known, one for what remains uncertain, and one for the next safe action. Include the evidence owner, the latest useful decision time, and the condition that would stop or reverse the action. This turns a technical result into a reviewable choice without pretending uncertainty has disappeared.
CHAPTER 7 OF 12 · Test what changes
7. Use encryption context as an authenticated boundary
An encryption context is nonsecret metadata cryptographically bound to an operation. It can bind an encrypted data key to tenant, object, schema or purpose. Decryption should require the same context.
Context does not hide metadata. Do not place secrets in it. Canonicalize names and values so equivalent records do not fail because of inconsistent encoding.
During migration, preserve or deliberately transform context. Rewrapping under the wrong tenant context can make data unavailable or weaken separation if authorization ignores the mismatch.
Evidence check: for Use encryption context as an authenticated boundary, preserve the observation before the interpretation. Record integrity verification before and after decoding. Then state the inference, one credible alternative, and the additional observation that would distinguish them. This compact audit keeps a fluent explanation tied to evidence that another reader can inspect.
Changed-context transfer: repeat this chapter’s decision after changing one consequential condition while holding the others fixed. Calculate or predict what should change, name the threshold or mechanism, and compare with the original case. If the conclusion survives, state the range tested; if it reverses, explain why. Transfer is demonstrated by the changed case, not asserted from the first example.
Practical decision record: write one sentence for what is known, one for what remains uncertain, and one for the next safe action. Include the evidence owner, the latest useful decision time, and the condition that would stop or reverse the action. This turns a technical result into a reviewable choice without pretending uncertainty has disappeared.
Maintain an index of object, encrypted-data-key version, wrapping-key identifier, algorithm suite, creation time, state and last verified recovery. Without inventory, teams cannot prove that a retiring key has no dependants.
Sample counts are not enough for destructive retirement. Reconcile storage listings with key-service use logs and migration records. Orphaned snapshots, replicas and archives can retain old dependencies.
The inventory also supports incident response. It bounds which objects used a key and which migrations must be prioritised.
Evidence check: for Inventory is a cryptographic control, preserve the observation before the interpretation. Record physical placement and correlated failure. Then state the inference, one credible alternative, and the additional observation that would distinguish them. This compact audit keeps a fluent explanation tied to evidence that another reader can inspect.
Changed-context transfer: repeat this chapter’s decision after changing one consequential condition while holding the others fixed. Calculate or predict what should change, name the threshold or mechanism, and compare with the original case. If the conclusion survives, state the range tested; if it reverses, explain why. Transfer is demonstrated by the changed case, not asserted from the first example.
Practical decision record: write one sentence for what is known, one for what remains uncertain, and one for the next safe action. Include the evidence owner, the latest useful decision time, and the condition that would stop or reverse the action. This turns a technical result into a reviewable choice without pretending uncertainty has disappeared.
CHAPTER 9 OF 12 · Check evidence and limits
9. Make migration writes atomic and recoverable
Store the new encrypted data key and its identifier in one conditional update. If the write fails, the old pair must remain intact. A mixed record—new identifier with old EDK—breaks recovery.
Use compare-and-set on the expected version. Concurrent writers may encrypt a new object version while the migration reads the old one. Version checks prevent the job from overwriting fresh metadata.
Quarantine failures with reason codes. Do not silently mark an object migrated because the job attempted it.
| Failure point | Unsafe result | Required control |
|---|---|---|
| After EDK creation, before write | Retry ambiguity | Idempotent state/version |
| Identifier written without EDK | Undecryptable object | Atomic pair update |
| Concurrent new object version | Migration overwrites fresh data | Compare-and-set |
| Verification fails | False completed state | Quarantine with reason |
Evidence check: for Make migration writes atomic and recoverable, preserve the observation before the interpretation. Record scrub interval, repair load and reduced-redundancy time. Then state the inference, one credible alternative, and the additional observation that would distinguish them. This compact audit keeps a fluent explanation tied to evidence that another reader can inspect.
Changed-context transfer: repeat this chapter’s decision after changing one consequential condition while holding the others fixed. Calculate or predict what should change, name the threshold or mechanism, and compare with the original case. If the conclusion survives, state the range tested; if it reverses, explain why. Transfer is demonstrated by the changed case, not asserted from the first example.
Practical decision record: write one sentence for what is known, one for what remains uncertain, and one for the next safe action. Include the evidence owner, the latest useful decision time, and the condition that would stop or reverse the action. This turns a technical result into a reviewable choice without pretending uncertainty has disappeared.
CHAPTER 10 OF 12 · Check evidence and limits
10. Limits, compromises and common misconceptions
Rewrapping does not repair plaintext exposure that already occurred. It also does not change ciphertext created under a weak data algorithm or reused nonce; those cases may require full re-encryption.
Key deletion is not a substitute for tested retention policy. Backups, legal holds and delayed replicas may still need recovery. Conversely, indefinite retention of every old key widens the compromise window.
Envelope encryption does not remove the need for access control, integrity, software security and recovery. A correctly wrapped key can still be misused by an over-privileged application.
Evidence check: for Limits, compromises and common misconceptions, preserve the observation before the interpretation. Record metadata version, catalogue and recovery history. Then state the inference, one credible alternative, and the additional observation that would distinguish them. This compact audit keeps a fluent explanation tied to evidence that another reader can inspect.
Changed-context transfer: repeat this chapter’s decision after changing one consequential condition while holding the others fixed. Calculate or predict what should change, name the threshold or mechanism, and compare with the original case. If the conclusion survives, state the range tested; if it reverses, explain why. Transfer is demonstrated by the changed case, not asserted from the first example.
Practical decision record: write one sentence for what is known, one for what remains uncertain, and one for the next safe action. Include the evidence owner, the latest useful decision time, and the condition that would stop or reverse the action. This turns a technical result into a reviewable choice without pretending uncertainty has disappeared.
CHAPTER 11 OF 12 · Practise and continue
11. Independent practice and changed-context transfer
Practice case: 600,000 objects share one logical wrapping-key identifier whose managed backing material rotates annually. Decide which components change automatically and which object records remain unchanged. Name the evidence needed before claiming historical data was rewrapped.
Changed context: the old key’s policy was overly broad but there is no evidence of cryptographic material compromise. Compare future-use rotation, rewrapping and full re-encryption. Explain why rewrapping may change the authorization boundary without rewriting bulk ciphertext.
Transfer to algorithm retirement. If the data ciphertext uses a disallowed algorithm, rewrapping only the data key is insufficient. Identify which layer must be regenerated and how rollback will preserve availability.
Evidence check: for Independent practice and changed-context transfer, preserve the observation before the interpretation. Record the failure pattern that exceeds the promise. Then state the inference, one credible alternative, and the additional observation that would distinguish them. This compact audit keeps a fluent explanation tied to evidence that another reader can inspect.
Changed-context transfer: repeat this chapter’s decision after changing one consequential condition while holding the others fixed. Calculate or predict what should change, name the threshold or mechanism, and compare with the original case. If the conclusion survives, state the range tested; if it reverses, explain why. Transfer is demonstrated by the changed case, not asserted from the first example.
Practical decision record: write one sentence for what is known, one for what remains uncertain, and one for the next safe action. Include the evidence owner, the latest useful decision time, and the condition that would stop or reverse the action. This turns a technical result into a reviewable choice without pretending uncertainty has disappeared.
Does key rotation re-encrypt all old data?
Often no. Managed key-material rotation commonly preserves the logical key and decrypts older ciphertext with retained material. Read the service semantics and inventory actual dependencies.
Is an encrypted data key secret?
It is ciphertext and is commonly stored with the protected object, but its integrity, context and access path still matter. The plaintext data key is sensitive keying material.
When is full re-encryption necessary?
Examples include retiring a weak data algorithm, correcting nonce misuse, changing the data key itself or meeting a policy that explicitly requires new bulk ciphertext.
For nearby distinctions, read secret sharing and threshold recovery and erasure coding and parity shards.
Authoritative sources include NIST SP 800-57 Part 1 Revision 5, the NIST definition of key wrapping, AWS KMS documentation on re-encrypting an encrypted object, and the AWS Encryption SDK concepts guide. Sources and links were checked on 22 October 2026.
Evidence check: for FAQ, sources and connected reading, preserve the observation before the interpretation. Record a test fixture decoded by the future system. Then state the inference, one credible alternative, and the additional observation that would distinguish them. This compact audit keeps a fluent explanation tied to evidence that another reader can inspect.
Changed-context transfer: repeat this chapter’s decision after changing one consequential condition while holding the others fixed. Calculate or predict what should change, name the threshold or mechanism, and compare with the original case. If the conclusion survives, state the range tested; if it reverses, explain why. Transfer is demonstrated by the changed case, not asserted from the first example.
Practical decision record: write one sentence for what is known, one for what remains uncertain, and one for the next safe action. Include the evidence owner, the latest useful decision time, and the condition that would stop or reverse the action. This turns a technical result into a reviewable choice without pretending uncertainty has disappeared.
Contents · Previous chapter · Return to the Information guide