Threat model

Who sees what

Party	Sees	Doesn’t see
BitTorrent swarm, trackers, DHT	The server’s IP address and that it downloaded the torrent	Anything from the server: it never uploads
iroh relays / network observers	That two endpoints talked, and roughly how much data moved	Plaintext, file names, the torrent name, the key
Someone with the ticket only	The ciphertext, file sizes and file count	Contents, file names, torrent name
Someone with the ticket and the key	Everything	—
Someone with the ticket and the reset token	Can switch the server to another torrent	The key for the current torrent
A notifier without include_key	The ticket, torrent name, size, file count	The key
Someone with root on the server during the download	Plaintext on disk	—

Promises

These are things deaddrop promises. Breaking one is a security bug:

• Confidentiality: no plaintext file contents, file names or torrent name without the key. The key is never written to the server’s disk or sent to a notifier without include_key.
• Integrity: fetch never accepts tampered or wrong-key data and never writes a partial file under its real name.
• Client file system: a malicious server can’t make fetch write outside the output directory.
• No seeding: no torrent piece data is uploaded and no incoming BitTorrent connections are accepted.
• Single use: a second client can’t download from a single-use server, and an old ticket stops serving data after a reset.
• Reset protocol: no reset without the right token, and a reset source is never read as a path on the server’s disk.
• Secrets in output: webhook URLs and reset tokens don’t show up in logs, deaddrop config check or error messages.

Known limits

Caution

These are by design and out of scope for security reports:

• File sizes, file count, and the fact that a transfer happened are not hidden.
• Plaintext exists on the server’s disk while the torrent downloads, and deletion is not secure erasure (especially on SSDs).
• The key appears on the server’s stderr/stdout, so a persistent log of that output contains it.
• Anyone holding the ticket can download the ciphertext; anyone holding both the ticket and the key can read it.
• The BitTorrent swarm, trackers and DHT can see the server’s IP address while it leeches.

Hardening tips

• Send the ticket and the key over different channels.
• Prefer the config file (chmod 600) or environment variables over command-line flags for webhook URLs, reset tokens and the key, to keep them out of shell history and ps.
• Use a long random reset token, e.g. openssl rand -hex 32.
• Only give include_key to notifiers you trust with the data.
• Don’t send the server’s stderr to a persistent log, or treat that log as a secret.
• Verify release downloads against SHA256SUMS.