Executive summary
deaddrop is a small self-hosted relay for transferring one encrypted file between two clients. The relay stores only ciphertext in memory, serves it once, and removes it on retrieval. Paired clients can derive short-lived slot addresses without exchanging a fresh URL, while an optional X25519 identity layer keeps an inner payload sealed from a malicious relay operator. The repository includes the Go implementation, deployment examples, protocol and threat-model documents, test vectors, and multiple bootstrap choices. It is a security-sensitive experimental tool with explicitly documented non-properties.
Problem and context
Common file-sharing systems retain server-side history, accounts, or durable objects. deaddrop explores a narrower handoff: the sender posts one encrypted object, the receiver consumes it once, and the relay forgets it. The design separates the capsule passphrase, deployment secret, short-lived slot address, and optional peer identity rather than treating one secret as every layer.
What was built
- A Go command-line client for pairing, key generation, fingerprinting, send,
- A small in-memory HTTP relay with strict consume-on-read semantics.
- Shared-capsule and interactive bootstrap paths, including OS-keyring identity
- Container and VM deployment examples.
- Protocol, specification, security, decision, testing, and future-work records.
- An optional MCP wrapper kept outside the core transfer protocol.
receive, and bootstrap flows.
storage where supported.
How it works
Clients share a passphrase-protected capsule containing pair material. For each handoff they derive an address from that capsule, time, and a separately deployed secret. The sender encrypts locally and uploads ciphertext. The receiver probes the current time window, retrieves once, and decrypts locally.
When the bootstrap identity layer is available, peers also retain X25519 keys in the operating-system key store. The content is then wrapped in an additional authenticated-encryption layer derived from the peer shared secret, so relay tampering does not expose or silently rewrite plaintext.
Evidence and validation
The repository organizes testing into tiers and includes fixed protocol vectors, bootstrap conformance cases, local end-to-end QA, collision and rollback cases, one-shot race behavior, crash/restart behavior, and an exit-code taxonomy. CI builds and tests the Go implementation, while the documentation maps security properties to their implementation or protocol layer.
Boundaries
The relay can observe timing, traffic volume, and network metadata. One-shot retrieval does not prevent a malicious receiver from copying plaintext after decryption. Security depends on correct client operation, secret provisioning, and the documented identity-store behavior of each platform. The specifications distinguish cryptographic properties from operational properties that depend on the reference relay.
Repository map and first run
make
make test
sh test/smoke/qa-roundtrip.shRead HOWTO.md for the operator path, PROTOCOL.md for the wire behavior, SECURITY.md for the threat model, and TESTING.md for the acceptance matrix. DECISIONS.md explains why the current bootstrap and deployment shapes were chosen over parked alternatives.