Home / Security

Thelemail encryption and threat model.

See how stored mail, internal messages, external delivery, passwords, keys and metadata are handled across the system.

How mail is encrypted If a server were compromised Not yet built

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.

Between accounts

End-to-end encrypted

Mail from one Thelemail account to another is encrypted on your device and decrypted on theirs. The server only ever relays ciphertext it has no key for.

Encrypted on your device, relayed as ciphertext, decrypted on theirs.

Your stored mailbox

Zero-access at rest

Everything in your mailbox is protected through a random account key. OPAQUE lets your password unlock the wrapped key on your device without sending us the password. We store ciphertext and don't hold the readable key material.

Protected through your account key; unlocked from its OPAQUE-wrapped form on your device.

To the outside world

Encrypted when possible

Outbound mail is encrypted end-to-end when the recipient publishes a compatible WKD/OpenPGP key. Otherwise it uses standard SMTP with TLS where supported, and Thelemail must process the readable content for delivery. Publishing your key through WKD lets compatible external senders encrypt inbound mail to you. External subject headers remain visible in either case.

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. The log is enrolled in the Witness Network staging list. Current browser, macOS and mobile clients enforce valid log proofs and two valid witness cosignatures out of three, no older than 24 hours. A missing or invalid proof or an unmet witness threshold blocks sending.

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.

The hard question

If a Thelemail server were compromised.

The measure of a security model is what an attacker gets when things go wrong.

What an attacker reaches

Exposure

Your stored mailbox contents

Protected Stored ciphertext only. The random account key is wrapped and unlocked on your device through OPAQUE; the server does not hold it.

Mail between Thelemail accounts

Protected End-to-end encrypted. The server never held a key that could read it.

Your account password

Protected OPAQUE lets your device prove knowledge of your password without sending it to us. We store an OPAQUE registration record, never the password.

Who you email, and when

Exposed Envelope metadata is visible; it's how mail is routed. We don't claim metadata privacy we don't have.

Mail you sent in plaintext to outside servers

Exposed Once it leaves for a server without a published key, it's out of our hands, and out of yours.

Subject lines of external mail

Exposed External subject headers remain visible, including when the message body is protected with WKD/OpenPGP. Internal end-to-end mail encrypts its subject inside the message.

A web client loaded after an active server compromise

Exposed A compromised web origin could try to serve altered client code on a future visit. Published source and build provenance make changes inspectable, but they do not remove this active-delivery risk.

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.

Honest about the gaps

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.

Not yet built

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 published

Not yet built

Metadata minimization

Envelope metadata is visible by design. Metadata-minimization techniques remain at the research stage.

Not yet built

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.

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.

Create free mailbox Read the threat model

Fay ce que vouldras. The only rule of the Abbey of Thélème. Rabelais, Gargantua, 1534.