What Happens When You Lose an Encryption Key

Zero-knowledge means the key is derived in your browser and never sent anywhere. Encrypt a document with AES-256-GCM and the readable version stays on your device; there is no server-side copy for an operator to read or restore.

The mathematics remove the escape hatch too. AES-256 sits in a keyspace of roughly 2^256 values, with no shortcut around that search, so no provider can guess or reverse a key for you. A provider able to return your files without your key would need a copy of it, and that copy is exactly what zero-knowledge refuses to keep.

In a hosted service with password resets, support can rebuild your access because the provider holds a recoverable credential. In zero-knowledge tools the operator genuinely cannot. A reset returns you to an account shell, since authentication is separate from encryption, and it decrypts nothing. No polite email bends that rule, and proving account ownership changes nothing.

You can confirm the boundary yourself. Open DevTools and watch the Network tab while you encrypt: no request carries the plaintext or the key. Run crypto.subtle.exportKey on a key handle not marked extractable and the promise rejects. The design is visible in the browser, not only in a claim.

Decide what happens when a device dies while you are calm, not while panicking. Write your recovery phrase on paper or a metal plate, and store it apart from the device holding the ciphertext. Then confirm the copy by restoring from it once on a spare device. An untested backup is a hope, and hopes fail at the worst moment.

Treat the recovery phrase as your highest-value secret, because it alone converts ciphertext back into readable content. Do not photograph it, paste it into a note synced to a shared account, or email it to yourself. If you keep encrypted exports, verify the export password the same way: a backup never restored is an unverified claim.

Convenience and recoverability pull in opposite directions, and every option sits somewhere on that line. Syncing keys through a cloud account is easy, but it hands custody to that provider and its reset flow. Keeping keys on one device resists remote compromise and collapses when a laptop is lost. You choose which failure to survive.

Recovery phrases follow the same logic. Twelve words from a large wordlist are easy to write down and, with enough entropy, hard to brute-force, but they are one object that opens everything if it leaks. A threshold scheme reduces that single-point exposure while adding a procedure you must practice.

A leaked key is worse than a missing one, because the data is readable now and possibly already copied. Loss is loud, since decryption fails, while compromise stays silent until you notice something odd. Rotate immediately: create a new key, re-encrypt what you can still reach, and destroy anything that used the old one. Assume everything the old key protected is exposed.

Encryption also does not save you from a compromised endpoint. If malware runs in the same browser session where you type your passphrase, it reads what you see, which no ciphertext design prevents. Check the origin and the TLS certificate first. NIST SP 800-38D covers authenticated encryption with GCM, and its integrity check catches modified ciphertext, but it cannot detect a hostile page reading your screen.