Security Model

DeadSwitch protects your most sensitive data — the kind of information where a breach isn’t just inconvenient, it’s catastrophic. Every design decision prioritizes security by default with no shortcuts.

Encryption at a Glance

Everything is encrypted at rest. There is no plaintext anywhere on the USB drive — not the database, not the media files, not the metadata. If someone steals the drive, they get a brick.

Why These Algorithms?

AES-256-GCM-SIV

Standard AES-GCM has a dangerous failure mode: if a nonce (initialization vector) is ever reused, the authentication key leaks catastrophically. GCM-SIV eliminates this risk. Even if a nonce collision occurs, the worst case is that an attacker can detect two identical plaintexts — not derive keys.

Why it matters: For a product where data integrity is literally life-and-death, “almost never fails” isn’t good enough. GCM-SIV provides a meaningful safety margin against implementation bugs.

Argon2id

Winner of the Password Hashing Competition. Argon2id combines two resistance properties:

• Memory-hard — Defeats GPU-based brute force by requiring large amounts of RAM per hash attempt
• Data-independent first pass — Resists side-channel attacks that try to extract the password by monitoring hardware behavior

DeadSwitch tunes Argon2id parameters to require significant memory and computation time. A brute-force attack against a strong master password is computationally impractical even with dedicated hardware.

XChaCha20-Poly1305

Used specifically for media encryption (video and audio messages). XChaCha20 uses 24-byte random nonces, which means nonce collision is statistically negligible even across billions of encryptions. Combined with Poly1305 for authentication, it provides fast streaming encryption without sacrificing security.

Four Security Modes

DeadSwitch lets you choose your own tradeoff between convenience and maximum security. Every mode uses the same encryption — the difference is where the key lives.

1. Local-Only

The encryption key exists only on the USB drive. Period.

• If our servers are compromised: your vault is safe
• If the USB is lost or destroyed: your vault is gone forever

Best for: Maximum security purists and users who maintain physical backup USBs. This is the “trust nobody” mode.

2. Cloud-Stored

An encrypted copy of your key is backed up to our server. If you lose the USB, you can recover your vault. The key is encrypted with your master password before upload — we never see the raw key.

• Server compromise + stolen master password = vault at risk
• Server compromise alone = attacker gets useless encrypted blob

Best for: Users who worry about USB failure or physical damage and want a recovery safety net.

3. Key-Split (Recommended)

The encryption key is split into two halves using XOR key splitting. One half stays on the USB. The other half lives on our server. Neither half alone can unlock anything.

This is the recommended mode for dead man’s switch users because it enables the server to release its half to beneficiaries when the switch triggers — while keeping your vault completely secure during normal operation.

• USB alone: useless
• Server alone: useless
• Both halves combined: unlocks the vault

Best for: Dead man’s switch users. This is the default mode and the one we recommend for most people.

4. Hybrid

Combines key-split operation with an encrypted cloud backup. You get the security of key-splitting (server can release to beneficiaries) plus the resilience of a recoverable backup (you can restore after USB loss).

Best for: Users who want both the dead man’s switch functionality and maximum protection against USB loss. Belt and suspenders.

Zero-Knowledge Architecture

Our check-in server runs the dead man’s switch state machine — tracking check-in intervals, escalation stages, and trigger conditions. Here’s exactly what it stores and what it doesn’t:

What the server knows

• Your email and hashed password (scrypt)
• Beneficiary contact information (email, phone)
• Encrypted key shares (encrypted with beneficiary-specific secrets)
• Check-in timestamps and switch state

What the server never sees

• Your master password
• Your vault encryption key (or its full form in key-split mode)
• Any vault contents — passwords, documents, messages
• Your media files — video, audio, images

If our server is breached: An attacker gets encrypted key shares that are useless without the beneficiary’s physical emergency card secret. They get hashed passwords that resist brute force. They get contact information. They do not get vault contents, encryption keys, or your master password. The physical USB drive remains completely secure regardless of what happens to the server.

Beneficiary Key Shares

When you add a beneficiary, DeadSwitch generates a unique 128-bit secret printed on their emergency card as 32 hex characters. Here’s the chain:

1. The secret encrypts the key material the beneficiary needs
2. The encrypted key share is stored on the server
3. When the switch triggers, the server emails the encrypted share to the beneficiary
4. The beneficiary combines the emailed share with their emergency card secret
5. This derives the decryption key for their portion of the vault

The server cannot decrypt the share alone — it needs the physical card secret that only the beneficiary possesses. An attacker who compromises the server gets encrypted shares with no way to use them.

Audit and Transparency

The vault encryption engine, cryptographic primitives, and core security components are open source. We believe that for a product handling your most sensitive data, “trust us” isn’t acceptable. You should be able to verify every cryptographic operation yourself.

Security through obscurity is not security. Every algorithm choice, every key derivation parameter, and every encryption operation is auditable. If you find a vulnerability, we want to know — responsible disclosure at security@dead-switch.com.