Security Model

Encryption Overview

DeadSwitch uses industry-standard cryptographic primitives throughout:

  • Vault encryption: AES-256-GCM-SIV (nonce-misuse-resistant authenticated encryption)
  • Key derivation: Argon2id with high memory cost parameters
  • Media encryption: XChaCha20-Poly1305 with random 24-byte nonces
  • Database: SQLCipher (AES-256-CBC encrypted SQLite)
  • Key shares: HKDF-derived beneficiary encryption keys

Why AES-256-GCM-SIV?

AES-256-GCM-SIV is a nonce-misuse-resistant AEAD (Authenticated Encryption with Associated Data) scheme. Unlike standard AES-GCM, if a nonce is accidentally reused, GCM-SIV does not catastrophically leak the authentication key. This provides a safety margin for a product where data integrity is literally life-and-death.

Why Argon2id?

Argon2id is the current winner of the Password Hashing Competition. It combines resistance to both GPU attacks (memory-hard) and side-channel attacks (data-independent memory access in its first pass). Parameters are tuned to require significant memory and time, making brute-force attacks against the master password impractical.

Four Security Modes

DeadSwitch offers four configurable security modes, letting users choose their own tradeoff between convenience and maximum security:

1. Local-Only

The encryption key exists only on the USB drive. This is the most secure mode — even if our servers were completely compromised, your vault remains safe. The tradeoff: lose the USB, lose everything. No recovery is possible.

Best for: Maximum security purists, users with physical backup USBs.

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.

Best for: Users who worry about USB failure and want a safety net.

3. Key-Split

The encryption key is split between the USB and our server using XOR key splitting. Neither the USB alone nor the server alone can unlock the vault. Both halves are required. This is the recommended mode for dead man’s switch users because it enables the server to release its half to beneficiaries while keeping your vault secure during normal operation.

Best for: Dead man’s switch users (recommended default).

4. Hybrid

Combines key-split operation with an encrypted backup. You get the security of key-splitting plus the resilience of a cloud backup. Most resistant to both USB loss and server compromise.

Best for: Users who want maximum resilience and use the dead man’s switch.

Zero-Knowledge Architecture

Our check-in server manages the dead man’s switch state machine (check-in intervals, escalation, trigger). It stores:

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

It does not store or ever see:

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

Even if the server were compromised, an attacker would get encrypted key shares that are useless without the beneficiary’s physical emergency card secret.

Beneficiary Key Shares

When you add a beneficiary, DeadSwitch generates a unique 128-bit secret (printed on their emergency card as 32 hex characters). This secret is used to encrypt the key material the beneficiary needs to unlock their portion of the vault.

The encrypted key share is stored on the server. When the switch triggers, the server sends the encrypted share to the beneficiary via email. The beneficiary combines this with their emergency card secret to derive the decryption key. The server cannot decrypt the share alone — it needs the physical card secret.

Audit and Transparency

The vault encryption and core security components are open source. We believe that for a product handling your most sensitive data, you should be able to verify every cryptographic operation yourself. Security through obscurity is not security at all.