Building a Zero-Knowledge Deadman Switch: Deep Dive<br>- Killswitch

Home

Blog

How We Built a Zero-Knowledge Dead man Switch: A Technical Deep-Dive

What "Zero-Knowledge" Actually Has to Mean

Most products that say "we encrypt your data" are telling the truth in a way that doesn't matter.

They encrypt at rest. They encrypt in transit. The encryption keys live on their servers. If they want to read your files — for analytics, for debugging, for compliance with a subpoena — they can. If their database is breached, the encrypted files and the keys to decrypt them tend to leave together.

Zero-knowledge means a stronger thing: the server cannot read your data, ever, even if it wanted to. Not because of policy. Because of math. The keys never exist on the server in unwrapped form. The decryption happens on the user's device, against ciphertext the server has been holding onto without ever being able to look inside it.

For a deadman switch — a system whose entire job is to hold your most sensitive documents and deliver them to specific people at specific moments — anything weaker than zero-knowledge is a backdoor with a friendly UI on top of it. (You'll also see the term written dead man's switch or dead man switch; same idea, different spelling conventions.)

Here's how the architecture actually works in Killswitch.

The Threat Model First

Before any code, the threat model. We assume:

The server will eventually be compromised. Maybe a breach, maybe a rogue insider, maybe a state-level subpoena, maybe an honest mistake by an engineer with shell access. We design as if "the server saw this in plaintext at some point" is a category of failure we want to make impossible.

The user is not a cryptographer. They will pick a password they can remember. They will check in from multiple devices. They will lose their phone. They will forget their backup codes. The system has to work for that user, not for someone running their own HSM.

The recipient may not have an account. Beneficiaries are often people who don't want to install anything. They get an email, they click a link, they download what was left for them. The crypto has to deliver across that boundary.

The deadman switch must fire even if the user's payment lapses, their email expires, or every device they own is gone. Recovery cannot depend on any single piece of infrastructure the user controls.

These four constraints define everything that follows.

The Core Primitive: Wrapped Master Keys

The architecture borrows directly from password managers like 1Password and Bitwarden. We didn't invent it; we adopted it because it's been adversarially studied for over a decade and the failure modes are well understood.

Here's the structure:

Layer 1 — User password. Never sent to the server. Used locally to derive a key.

Layer 2 — Key derivation. The user's password is run through PBKDF2-SHA256 with 600,000 iterations (current OWASP guidance for SHA-256) and a random per-user 16-byte salt. The output is a 256-bit derived key. This key is not used to encrypt files directly — it's used only to wrap the master key.

Layer 3 — Master key. Generated once, at signup, in the browser via window.crypto.subtle.generateKey. A random 256-bit AES-GCM key. This is the key that protects everything else.

Layer 4 — The wrap. The master key is wrapped (encrypted) using the password-derived key, with AES-GCM and a fresh 12-byte IV, then sent to the server. The server stores the wrapped master key — encrypted bytes it cannot decrypt without the user's password, which it does not have.

When the user logs in, the wrapped master key comes down to the browser. The user's password derives the wrapping key. The wrapping key unwraps the master key. The master key now exists in browser memory. Files can be decrypted. The server still has no idea.

Why this matters for password changes. If you encrypt files directly with a password-derived key, changing your password means re-encrypting every file. With wrapped master keys, password changes re-encrypt only one tiny piece of data (the wrap), not the gigabytes of files. Password changes complete in milliseconds regardless of how much you've stored.

Why this matters for security. A compromised server gets ciphertext and a wrapped master key. Both are useless without the user's password.

Why we wrap the master key with a password-derived key, instead of using the password-derived key directly. The wrapped master key pattern decouples "what encrypts your files" from "how your password derives the wrapping key." That decoupling has two practical payoffs:

Password changes are instant. A new password produces a new password-derived key, which re-wraps the same master key. The master key bytes don't change, so files, content keys, and shares are all still readable. We update three small columns and we're done. Naïve designs that encrypt files directly with a password-derived key turn a password change into re-encrypting every file the user has...