Trust
Security
The algorithms, the trust boundaries, and how to verify the client you are running.
Verifiable, or it didn't happen.
The evidence trail behind every transfer — check it yourself, not just on our word.
- Whitepaper
Protocol design: post-quantum handshake, retention guarantees, relay trust model.
Read the whitepaper → - Audit
Independent review — none published yet; scheduled 2027-Q1.
Audit status → - Build hashes
Reproducible builds — SHA-384 of WASM+glue, verify in browser.
Verify build hashes → - Source
Licence: AGPL-3.0 · Source publication pending — 2026-10-01
- Canary
Signing canary pending — key ceremony (D-02) · first signed canary follows publication.
Room state and file chunks exist only in the process memory of a single relay
worker — never serialized, never logged, never backed up. On completion or timeout that memory is
zeroized (Rust zeroize, Drop-guarded). The relay’s operational
log keeps only timestamp · method · path · status · latency · bytes, with IP
addresses stripped at the TLS terminator — the full field inventory lives on
/transparency.
Verify this transfer yourself
Don't trust the page — check it.
…
Room-key fingerprint appears here while a room is open.
- KEM
- ML-KEM-1024 ✓ (FIPS 203, L5)
- AEAD
- AES-256-GCM ✓ (counter-based 96-bit nonces)
- Hash
- BLAKE3 ✓ (root: unavailable — no transfer in scope)
At a glance
- Key Exchange
- ML-KEM-1024 (FIPS 203)
- Encryption
- AES-256-GCM
- Hash
- BLAKE3
- Storage
- In-memory only, never written to disk
Detail
Threat model
In End-to-end mode the relay is fully untrusted: it sees ciphertext and a one-way room derivation — never plaintext, filenames or keys. Even a compromised relay cannot read an End-to-end transfer. (Transport-only mode is relay-carried by design: those bytes ride the relay directly.)
Peers authenticate through a password-authenticated key exchange with safety numbers; the sender-side identity is verified against the code you exchanged out of band.
In End-to-end mode, files are encrypted in the browser before they leave the device and are decrypted only on the receiver. Nothing is written to disk on our side, and nothing is retained after the room closes.
Cryptography
Key exchange: hybrid ML-KEM-1024 (FIPS 203) + X25519 (RFC 7748). Both algorithms must be broken to compromise a session — the hybrid keeps classical and post-quantum assumptions independent.
Symmetric encryption: AES-256-GCM with HKDF-SHA256 key derivation and counter-based 96-bit nonces.
Integrity: BLAKE3, with a Merkle tree over the file so large transfers verify incrementally on the CLI lane; the browser lane rests on the per-chunk AES-GCM tags plus the transport. SHA3-256 is used only where a NIST-required context asks for it.
Key derivation from codes and passwords: Argon2id (memory-hard), with the room-code profile sized for the browser.
Memory safety and zeroization
The engine is Rust, compiled to WebAssembly; no unsafe code ships without a documented SAFETY justification.
All key material is zeroized on drop, pinned in RAM (mlock) and never swapped to disk. Core dumps are disabled (prctl(PR_SET_DUMPABLE, 0), ulimit -c 0).
Secret-dependent comparisons use constant-time primitives (subtle).
Relay zero-knowledge design
The relay receives a room identifier derived one-way from the passcode, forwards encrypted bytes between participants, and stores nothing to disk.
Rooms expire automatically (default 10 minutes), and abuse controls are being migrated to proof-of-work challenges rather than IP keying — a design that keys on IP cannot stay private.
Operational logs are structured and address-free: timestamp, method, path, status, latency, bytes. There are no crash reporters in production or in the web app.
Optional Tor / onion access
The site and relay are also reachable as a Tor v3 onion service for users who want to route around IP-level observation entirely.
Pages loaded from the onion enter tor-mode automatically: no WebRTC, no WebTransport, and scaled timeouts for circuit latency.
Nothing is required: the clearnet site is fully functional without Tor.
Go deeper
- Security model — the full threat model, adversary profiles and STRIDE analysis.
- Rate limiting design — the proof-of-work challenge that replaces IP keying.
- security.txt — the machine-readable disclosure contact.