Technical
Tallow Whitepaper
Draft v1.0 · September 2026 · licensed AGPL-3.0
Abstract
Tallow is an ephemeral, end-to-end encrypted file-transfer service. A sender drops files into a room in the browser; the receiver opens a link; the ciphertext transits an untrusted relay that stores nothing and is designed to forget. The design goal is narrower than "secure file sharing": it is that nothing you transfer becomes durable infrastructure — not on our disks, not in our logs, not in a backups bucket, not in a support database. This document states the architecture, the cryptographic choices, the operational hardening, and — just as deliberately — what the system does not claim.
1. Ephemerality as the primary property
Most transfer tools treat storage as the product and encryption as a feature. Tallow inverts that: the transfer channel is the product, and the absence of storage is the security property. Rooms exist in relay memory for the life of the transfer; files are encrypted in the sender's browser before the first byte leaves the device; the relay forwards ciphertext and routes it. When the room ends, there is nothing left to retain, subpoena or leak. "Designed to forget" is therefore not a tagline bolted onto the architecture — it is the architecture.
2. Cryptographic design
Key exchange is hybrid: ML-KEM-1024 (FIPS 203, Security Level 5) combined with X25519 (RFC 7748). Hybrid matters because the two mechanisms fail differently. A future quantum computer breaks X25519 outright; ML-KEM-1024 is sized for a 15-year threat horizon against it. X25519, in turn, is the classical construction with the deepest real-world cryptanalysis — if a lattice assumption behind ML-KEM were to weaken, the classical half still holds. An attacker must break both. Payload encryption is AES-256-GCM (AEAD — confidentiality and integrity in one pass), and content hashing uses BLAKE3. The transport is TLS 1.2/1.3 with AEAD cipher suites and forward secrecy; the TLS 1.3 handshake itself negotiates the X25519MLKEM768 post-quantum hybrid, so even the channel is not waiting for quantum migration.
3. No-storage architecture
Three properties keep the service in the "nothing stored" class: (1) keys are derived and held in the browser — in End-to-end mode the relay never sees plaintext or key material; (2) room state lives in relay memory only, and is discarded when the room expires or the transfer completes; (3) no upload is written to disk on our side — there is no object store, no backup set, no retention window to configure. The relay's operational logs are structured and address-free (timestamp, method, path, status, latency, bytes), allowlist-only; IP addresses are stripped at the TLS terminator before any log write. The full inventory of what exists, for how long, is published on the transparency page.
4. Operational hardening
The honest version of "memory only" has to confront the ways memory leaks: swap, core dumps, crash reporters, and log verbosity. Secrets are pinned in RAM (mlock) so they cannot be paged to swap; core dumps are disabled on the relay host (PR_SET_DUMPABLE=0, ulimit -c 0, kdump off in production) so a crash cannot spill key material to disk; third-party crash reporters are not used, because their whole job is uploading memory context; and the log schema is enforced in the type system — fields are allowlisted, so adding a sensitive field is a compile error, not a code-review note. The evidence for each of these controls is published in the security documentation, with the checks that reproduce it.
5. Verifiability
Claims should be checkable without trusting the claimant. The client is published as a WebAssembly package with SHA-384 SRI hashes in /pkg/manifest.json; /selftest.html hashes the engine bytes this device actually loaded and compares them against that manifest; the build steps for reproducing the hash from source are documented; and the source itself is AGPL-3.0. Independent third-party audit status is stated plainly on /security/audit — including when the answer is "none yet" — because a trust surface that only reports good news is a marketing page, not a trust surface.
6. What this document does not claim
No formal verification of the client. No completed third-party audit (see /security/audit for the dated status). No protection against an adversary who controls your device: if the endpoint is compromised, end-to-end encryption protects the transfer, not the endpoint. No anonymity network: Tallow is not Tor, and the relay necessarily sees connection metadata while a room is live. And no warrant canary yet — the signing-key ceremony that makes a canary meaningful is not complete, so the footer and the transparency page say so instead of shipping theatre.
7. Document status
Working draft v1.0, September 2026. This page is versioned in place: as the architecture changes and reviews complete, the version and date change with it.