Project: encrypted local draft lifecycle

Last updated: 4 Oct 20268 min read

project

Build an optional local vault for inspector 62's private case drafts. First write a threat model: encrypted bytes may protect stored drafts after a lost device or storage inspection, while code running in an unlocked page can still read plaintext. Keep authentication, record authorization, and server checks separate from the vault. Each record stores a format version, account and record IDs, key version, fresh nonce, ciphertext, and authentication tag. The account and record binding enters authenticated additional data, so swapping the ciphertext between records fails. A password unlock derives a wrapping key using a per-vault salt and a measured work factor, then unwraps the data key; losing the password and recovery material may make offline data unreadable. Never claim that browser storage of an encrypted key grants an independent secret when page code can obtain the key after unlock. A rotation writes a new envelope alongside the old one, verifies that it can decrypt a test record, and only then retires an old envelope under the recovery policy. A server-side session revocation stops future authorized requests but cannot erase an offline copy already held on a lost device. The interface states this boundary before enabling the feature.

Build contract

Reject ciphertext moved to another account or record.
Never reuse a nonce with the same AES-GCM key.
Leave a verified recovery route before retiring an old key envelope.
Explain to users what a lost password or stolen unlocked device means.

Implementation checkpoint

function mayRetireEnvelope(rotation) {
  return rotation.newEnvelopeStored && rotation.decryptVerified && rotation.recoveryConfirmed;
}
console.log(mayRetireEnvelope({ newEnvelopeStored: true, decryptVerified: false, recoveryConfirmed: true }));
// Output: false

Cost and boundaries

Authenticated encryption processes each byte, so encrypting a record takes O(record bytes) time and stores nonce and tag overhead beside ciphertext. Password derivation adds a deliberate unlock delay; measure it on supported low-end devices, because a fixed iteration count is not a universal security setting. Rewrapping a data key is small compared with re-encrypting every draft, but retaining two valid envelopes increases key custody work during rotation. A recovery export needs explicit consent, integrity checks, and a privacy-safe destination. Server synchronization still needs revision and authorization checks, and encrypted content can limit server-side search or inspection if the server cannot decrypt it.

Failure drill

Encrypt two records with separate nonces. Swap their ciphertext packages and verify authentication fails when account and record IDs are bound to additional data. Corrupt one byte and ensure the app does not replace an existing good draft with partial plaintext. Start rotation and simulate a write failure after the new envelope is stored but before decryption verification. Reopen with the old envelope and keep the record readable. Now lose the password with no recovery key and show the documented loss state rather than inventing a reset. Unlock on a shared computer, inject a script into a controlled test page, and demonstrate that page code can access decrypted material; fix the injection path instead of advertising encryption as script isolation.

Acceptance checks

Tampering and record swaps fail closed without leaking partial data.
The old envelope remains until the new one and recovery are verified.
Unlock cost and storage overhead are measured on target devices.
The threat model separates lost storage from a compromised running page.

Common Mistakes

Using a password directly as an AES key.
Reusing a nonce after an interrupted write or restore.
Deleting the only readable envelope before a restore drill.

web-tech

web-development