Architecture

Overview of the Dead Letter architecture.

Architecture

DeadLetter is a privacy-first, offline-capable dead-drop communication system built around three principles:

1. No persistent sender identity
2. Receiver-controlled trust
3. Zero-knowledge infrastructure

The system is composed of four independent layers:

1. Device Layer (ESP32 DeadDrop)

The ESP32 device is responsible for:

• Generating ephemeral encryption keys
• Encrypting payloads using X25519 + AES-256-GCM
• Never storing plaintext
• Never learning recipient private keys

Each device only knows:

• Its own device ID
• The gateway addresses (registry + backend)
• A pinned root trust fingerprint

2. Registry Layer (Trust Authority)

The registry acts as a minimal Certificate Authority.

Responsibilities:

• Issues signed certificates binding:
  • handle
  • encryption public key
  • keyId
  • expiry
• Signs certificates with a long-lived root signing key
• Publishes the root public key at /keys/

Security properties:

• Registry never sees messages
• Compromise cannot decrypt past traffic
• Clients verify all certificates locally

3. Backend Layer (Dead Drop Store)

The backend is a dumb encrypted mailbox.

Responsibilities:

• Accepts encrypted envelopes via POST /post
• Returns encrypted envelopes via GET /inbox/:handle
• Deletes messages only after:
  • Signed delete request
  • Verified against registry certificate

Security properties:

• Backend cannot decrypt messages
• Backend cannot forge delete requests
• Messages expire automatically (TTL purge)

4. Client CLI Layer

The CLI is the user's trust anchor.

Responsibilities:

• Fetches and verifies registry root key
• Verifies receiver certificates
• Derives shared secrets locally
• Decrypts messages
• Signs delete acknowledgements

The CLI never transmits private keys.

Message Flow

ESP32 Sender → Encrypt → Backend Store → CLI Fetch → Decrypt → Signed Delete

Threat Model Summary

Compromising any single layer is insufficient to break privacy.