Security Model

DeadLetter is designed as a trust-minimized dead drop messaging system.
No single component can read or forge messages, even if fully compromised.

This document describes the threat model, trust boundaries, and cryptographic guarantees.

Threat Model

We assume the following adversaries may exist:

We do not assume any server is honest.

Core Guarantees

DeadLetter provides:

• End‑to‑end encryption — only sender and receiver can read messages
• Forward secrecy — compromise of long‑term keys does not reveal past messages
• No backend trust — backend stores opaque blobs only
• No registry trust — all registry data is signed and verified by clients
• Offline‑safe messaging — sender and receiver never need to be online simultaneously

Key Types

Each identity owns two keypairs:

Certificate Chain

1. Registry has a root signing key.
2. Each user certificate is signed by this root.
3. Clients verify:

root_pub -> verifies -> user_cert -> authorizes -> encryption_pub

The backend never sees private keys.

Message Encryption

Every message uses a new ephemeral keypair.

sender_ephemeral_priv + receiver_enc_pub
        ↓ X25519
     shared_secret
        ↓ HKDF
     session_key
        ↓ AES‑256‑GCM
     ciphertext

Salt:

SHA256(ephemeral_pub || receiver_pub)

Message Deletion Authorization

When a user deletes a message, the client signs:

"<message_id>:delete"

using its Ed25519 signing key.

The backend verifies this signature against the registry certificate.
No one else can delete your messages.

Metadata Leakage

DeadLetter intentionally minimizes metadata but cannot eliminate:

• IP addresses (unless Tor used)
• Timing correlations
• Message sizes

Trust Boundaries

Security Properties Summary

DeadLetter is built on the assumption that servers will eventually be hostile.
Your security lives entirely on your devices — and that is exactly the point.