Skip to content
AITroveRead. Build. Understand.
Reading list
Make this comfortable

Key Rotation, Envelopes, and Device Loss

Last updated: 4 Oct 20267 min read
tutorial
IntermediateBy AITrove Editorial

Key rotation changes which key encrypts future data and, when required, migrates existing envelopes. Each stored record needs a key ID and format version so readers can select the correct key during a transition. A rotation is not complete merely because a new key was generated; old ciphertext, offline devices, backups, and exports still exist. Revoking a key can stop a cooperative app from decrypting new downloads, but it cannot erase plaintext or ciphertext already copied elsewhere. Define the supported device and backup window before changing keys.

Working case

Reviewer 47 reports a lost tablet that held encrypted drafts for case 62. The server revokes that device session and future synchronization, while the team assesses whether its browser key was protected by a separate unlock factor. On another device, release 29 creates key version 4 for new drafts. Existing local envelopes tagged version 3 remain readable during a controlled migration. The application writes a version-4 envelope and verifies decrypt before deleting the version-3 local copy. The incident record does not promise deletion from the lost tablet, because it may never reconnect.

Implementation boundary

javascript
function mayDiscardOldEnvelope(rotation) {
  return rotation.newEnvelopeWritten && rotation.newEnvelopeVerified && rotation.backupPolicySatisfied;
}
console.log(mayDiscardOldEnvelope({ newEnvelopeWritten: true, newEnvelopeVerified: false, backupPolicySatisfied: true }));
// Output: false

Store algorithm, envelope version, key ID, nonce, and authenticated record metadata with each ciphertext. Maintain a narrow reader window for old key IDs while re-encrypting in batches. Write the new envelope first, verify it under the new key, then atomically mark the migration complete for that record where storage permits. Pause synchronization of a record whose migration state is uncertain. Keep a backup or export recovery plan for key loss, subject to the chosen privacy model. On account switch, remove usable key references and local plaintext, but keep server authorization as the decisive barrier to future records. Audit key issuance, rotation, and retirement without logging key material.

Cost and boundaries

Re-encrypting n records of total size b takes O(b) cryptographic work and can temporarily require close to twice the local bytes. On a nearly full device, rotation may fail due to quota even though normal edits still fit. Batch work and expose progress, cancellation, and resume state. Retaining old keys extends exposure, so set a retirement deadline tied to observed migration and backup policy. A lost offline device may never acknowledge rotation; device revocation should stop server access while the product explains the limit of local deletion.

Failure trace

The app overwrites a version-3 envelope with a version-4 ciphertext before verifying that the new key can read it. A crash leaves the only draft unreadable. Reproduce a crash between write and verification, a full-storage error during rotation, a missing old key, and two devices on different releases. The migration must preserve a readable old copy until success, then retire it according to policy. Simulate a lost tablet staying offline forever; the server must deny future writes from its revoked session without claiming it erased local bytes.

Verification

  • Every envelope names the key version needed to read it.
  • A crash or quota failure leaves a readable old copy.
  • Revoked device sessions cannot replay to the server.

Practice drill

Create 47 encrypted draft envelopes tagged key version 3. Rotate a few to version 4, interrupt the process, and resume without duplicating or dropping a record. Force a quota failure and show the user which records remain on version 3. Revoke a lost device and attempt server replay with its old session. Inspect the rotation audit: it should name key IDs, counts, and outcomes, never raw key bytes or note text.

Decision note

Rotation is a verified data migration plus access revocation; neither operation can undo a prior copy.

Common Mistakes

  • Generating a new key and calling old data rotated.
  • Deleting the only readable ciphertext before verification.
  • Promising remote erasure from a device that stays offline.

Related lessons

Browser Cryptography and Key Custody; Browser Encryption Threat Model and Key Custody; Authenticated Encryption, Nonce, and Record Binding; Password Unlock, Derivation, and Recovery; Backup Restore with Deletion Tombstones; Browser Storage Cleanup on Account Change.

Connected practice

Build Project: encrypted local draft lifecycle and review Web Development: offline and browser-key decisions quiz.

web-tech
web-development
Storage details