Thelemail encryption and threat model.
See how stored mail, internal messages, external delivery, passwords, keys and metadata are handled across the system.
Three different guarantees. Stated separately, on purpose.
"End-to-end encrypted" means different things depending on where mail goes. Combining the cases into one claim hides material differences, so each path is documented separately.
End-to-end encrypted
Encrypted on your device, relayed as ciphertext, decrypted on theirs.
Zero-access at rest
Protected through your account key; unlocked from its OPAQUE-wrapped form on your device.
Encrypted when possible
WKD/OpenPGP when a key exists; standard SMTP otherwise. External subjects stay visible.
Your keys live in a signed, logged directory. When you encrypt to another account, you fetch its public key from a directory we sign, and every key we publish is written into an append-only transparency log you can read yourself. See the log's identity, keys and current state. Its Witness Network staging enrollment is confirmed and the live checkpoint carries witness cosignatures; client enforcement is not active yet and is marked below.
Your password stays on your device. Thelemail uses OPAQUE, an augmented password-authenticated key exchange. The server stores an OPAQUE registration record, while your device uses the protocol to authenticate, unwrap the random account key and decrypt your private key without sending us your password.
Inbound external mail crosses a plaintext boundary unless the sender encrypts it. Compatible senders can discover your public key through WKD and send OpenPGP-encrypted mail. Other inbound mail is classified for spam in memory, encrypted for your account and stored only as ciphertext.
If a Thelemail server were compromised.
The measure of a security model is what an attacker gets when things go wrong.
One consequence worth stating plainly. Your password and recovery method are the ways your device can unlock the wrapped random account key. Losing both means even we cannot restore your mailbox. That is the zero-access guarantee working as intended.
What we haven't built yet.
A page that only listed strengths would be marketing. These are real limitations, named plainly, marked not yet built until they are.
Independent third-party audit
We have not commissioned an external security audit, and we won't imply one until the report exists and we can link to it. The browser client and the transparency log server are public, so independent researchers can review them directly, and we'll point to their findings, good or bad.
What is publishedIndependently witnessed key log
The key transparency log is live, open source and enrolled in the Witness Network staging list. Its checkpoints carry witness cosignatures, and the browser and macOS desktop clients pin a two-of-three witness threshold. Runtime enforcement is not active yet: until it is, clients check proofs and cosignatures and do not refuse a message when a check fails.
The log's identity and current stateMetadata minimization
Envelope metadata is visible by design. Metadata-minimization techniques remain at the research stage.
Formal compliance certifications
We run in the EU and say so. We don't hold SOC 2 / ISO certifications yet, so we don't claim them.
Fay ce que vouldras. The only rule of the Abbey of Thélème. Rabelais, Gargantua, 1534.
We wrote down what we can't protect.
The threat model spells out what is encrypted, what is not, and what a server compromise would and would not expose. The gaps we haven't closed yet are listed with it.