Security

Architecture Overview

Delete Upon Death uses a zero-knowledge architecture. This means our servers store only encrypted data that we cannot read. Here's how it works:

// What happens on YOUR device:

1. You enter username + password
2. Username → hashed with Argon2id → becomes account_id
3. Password → derived with Argon2id → becomes master_key
4. Your files → encrypted with master_key → becomes encrypted_blob

// What we store on our servers:

account_id       ← cannot be reversed to username
encrypted_blob   ← cannot be decrypted without your password

// What we NEVER receive:

username         ← never transmitted
password         ← never transmitted
master_key       ← never transmitted
plaintext files  ← never transmitted

Cryptographic Algorithms

We use industry-standard, well-audited cryptographic algorithms:

Why These Choices?

• Argon2id — Winner of the Password Hashing Competition. Resistant to GPU/ASIC attacks due to memory-hardness. The "id" variant protects against both side-channel and GPU attacks.
• AES-256-GCM — Authenticated encryption providing both confidentiality and integrity. Used by TLS 1.3, government agencies, and security-critical applications worldwide.
• Per-file keys — Each file has its own random encryption key. Even if one key were somehow compromised, other files remain protected.

Post-Quantum Resistance

A sufficiently powerful quantum computer running Shor's algorithm would break today's public-key cryptography (RSA, ECC). That threat doesn't exist yet, but the cryptographic community generally assumes encrypted data captured today could be decrypted in the future once the hardware catches up ("harvest now, decrypt later"). Here's where we stand:

The vault data path is post-quantum resistant by design

The encryption that protects your files uses only symmetric primitives:

• Argon2id — key derivation from your password. Symmetric, not Shor-vulnerable.
• AES-256-GCM — file encryption. Against Grover's algorithm (the best known quantum attack on symmetric ciphers), AES-256 retains ~128 bits of effective security — still computationally infeasible.
• No asymmetric keys — the vault never uses RSA, ECDH, or ECDSA for file storage, key exchange, or inheritance. A quantum adversary has nothing to attack here.

If someone captures your encrypted vault today and sits on it until a cryptographically relevant quantum computer exists, it is still meaningless without your password.

What is not post-quantum yet

Honesty matters more than marketing, so here's what's still classical:

• TLS 1.3 transport — the HTTPS connection to our servers uses classical key exchange (X25519/P-256). A quantum break on TLS would expose what's transmitted in transit, but vault contents are already encrypted client-side before TLS — a TLS break alone doesn't decrypt your files.
• WebAuthn / FIDO2 hardware keys — use P-256 ECC signatures. This is an authentication factor, not a decryption key. A quantum adversary could potentially forge an assertion, but could not use that to read vault contents.
• Contact form — our encrypted contact page uses RSA-4096 for key wrapping. This is isolated from vault storage. Migration to ML-KEM (CRYSTALS-Kyber) is on the roadmap.

Roadmap

As NIST-standardized post-quantum algorithms (ML-KEM, ML-DSA) mature in web-platform APIs, we'll migrate the remaining asymmetric surfaces to hybrid post-quantum schemes. The vault data path requires no change — it's already there.

Threat Model

Security is about trade-offs. Here's what we protect against — and what we don't:

Infrastructure Security

• Encryption at rest — All servers use full-disk encryption (in addition to your client-side encryption)
• Encryption in transit — TLS 1.3 for all connections. No legacy protocol support.
• Network isolation — Database and storage are not publicly accessible
• Access logging — All administrative access is logged and audited
• Minimal access — Principle of least privilege for all systems
• Regular updates — Security patches applied promptly
• DDoS protection — Infrastructure-level protection against denial of service

Security Audits

Vulnerability Disclosure

We welcome responsible security research. If you discover a vulnerability:

• Email security@deleteupondeath.com
• Include detailed steps to reproduce
• Give us 90 days to fix before public disclosure
• We do not pursue legal action against good-faith researchers