Security Practices

Plain-English details on how DeadDrop protects your data.

Last updated:

End-to-End Encryption

Your content is encrypted on your device before it leaves. We store ciphertext only.

Zero-Knowledge

We cannot decrypt your Drops. Keys are never shared with our servers in plaintext.

Secure Uploads

Small files and multi-part large files are encrypted chunk-by-chunk with authenticated encryption.

How encryption works

Each Drop has its own randomly generated Data Encryption Key (DEK). Your device encrypts the Drop’s message and attachments with the DEK using authenticated encryption (AES-256-GCM). The encrypted result (ciphertext + authentication tag) is sent to our servers for storage and delivery.

Why this matters: even if someone accesses our databases, the data remains unreadable without your keys.
  • Per-Drop keys: a unique DEK per Drop prevents cross-Drop impact.
  • AEAD integrity: AES-GCM provides confidentiality and tamper detection.
  • Modern derivations: user-derived secrets (where applicable) are hardened with PBKDF2-style derivation.

Files & large uploads

Attachments are encrypted on-device. For large files, we use multi-part encryption: your file is split into parts, each part is encrypted with AES-GCM and uploaded. We derive a unique IV per part (non-repeating, part-specific) and include an authentication tag so tampering is detected.

  • Small files: encrypt as a single payload.
  • Large files: client-side chunking; each chunk is independently protected with its own tag.
  • Resume safety: if a part fails, only that part is retried—keys never leave the device in plaintext.

Keys & device pairing

Your private keys are kept in a secure local vault on your device. To bring a second device online, you use a short-lived pairing channel. Devices exchange encrypted setup messages via the relay, and only the devices can read them.

  • No plaintext keys on servers: pairing messages are encrypted end-to-end.
  • Time-boxed channels: pairing links expire automatically to reduce risk.
  • Manual control: you can rotate a Drop’s DEK at any time; recipients get updated links.

Delivery rules & heartbeats

DeadDrop can release a Drop on a fixed date/time or after a period of inactivity (heartbeat not seen). Heartbeats are lightweight authenticated pings your device sends. If the deadline passes without a heartbeat, the server delivers your encrypted Drop to the chosen recipients.

  • Time-based: you pick the local date/time and timezone; we store it as such and compute safely in UTC.
  • Inactivity-based: you define how many days of silence must pass before release.
  • Manual send: you can dispatch links immediately when needed.

What we store vs. what we never store

We store (encrypted or minimal)

  • Ciphertexts of messages and files
  • Delivery metadata (created/updated dates, schedule rules)
  • Recipient identifiers and invite link tokens
  • Plan/usage counters (bytes, file counts)

We never store (plaintext)

  • Plaintext secrets or attachments
  • Plaintext DEKs or private keys
  • Your app passphrase

Account & recovery

Because we use end-to-end encryption, we can’t recover content without your keys. We recommend:

  • Enable a second device and verify pairing works before you rely on it.
  • Securely store any recovery info you choose to export.
  • Rotate a Drop’s DEK if you suspect a device compromise.

See also the FAQ for practical guidance.

Transparency & updates

We continuously improve DeadDrop’s security. If we make material changes, we’ll update this page and the app. For operational uptime and incidents, visit the Status page. For questions, Contact Us.