End-to-end encryption (E2EE) in SipherMail is optional and works per message. This post explains the mechanism step by step, then lists what it does not protect. We describe only the message body here.
The short version#
Your browser or app encrypts the body of a message before sending it. The server stores and forwards ciphertext. Only people holding a matching private key can decrypt it, and that key is itself locked with a passphrase that is not your login password.
Step 1: you get a key pair#
When you set up encryption in Settings > Encryption, your device generates an RSA key pair. The key size is 4096 bits, and the algorithm is RSA-OAEP with SHA-256.
- The public key is stored on the server so other SipherMail users can encrypt messages to you.
- The private key is encrypted on your device before it is uploaded. It is protected with AES-256-GCM, using a key derived from your passphrase with PBKDF2 (SHA-256, 310,000 iterations).
So the server holds your private key, but only in encrypted form. Without your passphrase it is not usable. The key work happens in the browser using the Web Crypto API.
Step 2: each message gets its own key#
When you send an encrypted message:
- Your device generates a fresh random AES-256 key for that one message.
- It encrypts the body with AES-256-GCM, which also authenticates it so tampering is detected.
- It wraps the AES key with RSA-OAEP, once for each recipient’s public key.
- It also wraps the key for your own address, so you can open your Sent copy.
- It packs the result into one text payload.
The payload looks like this:
SIPHER-E2EE-V1::<encrypted key>::<iv>::<ciphertext>The parts are separated by :: and each part is Base64. With several recipients, the key part holds one wrapped key per address. The iv is the random value AES-GCM needs for each encryption.
Your signature is part of the encrypted body. If you quote an earlier message in a reply, the quoted text is added after the encrypted payload in the clear, so keep that in mind when replying to something sensitive.
Step 3: what the server stores#
The server stores the payload exactly as sent: ciphertext, wrapped keys and the random value. It never receives the per-message AES key in usable form, and it never receives your unlocked private key. That is why an encrypted message cannot be read by the server.
To read a message, your device fetches your encrypted private key, unlocks it with your passphrase, unwraps the AES key for that message, and decrypts the body locally.
Passphrase versus login password#
These are two different secrets with different rules.
| Login password | Encryption passphrase | |
|---|---|---|
| Used for | Signing in | Unlocking your private key |
| Can we reset it | Yes, through the normal reset flow | No, not on the web |
| If you lose it | Reset and carry on | Encrypted messages become unreadable |
On the web, you choose the passphrase and it cannot be recovered. That is the price of the server being unable to read your encrypted mail. Write it down somewhere safe. Resetting your login password does not touch it.
On the mobile apps, automatic setup keeps a random passphrase in the device keychain and gives you a recovery code. Store that code outside the phone.
When you can use it#
E2EE needs the recipient to have a SipherMail public key. If you write to someone on another service, the message goes out as ordinary email. You cannot combine E2EE with expiring or password-protected messages, which are a separate feature with their own protection.
What E2EE does not protect#
This is the part people skip, so we will be direct.
- Ordinary mail. Everything you receive from other services, and normal messages you send, is readable by the mail server. E2EE only covers the specific encrypted messages described above.
- The subject line. The subject is sent as a separate field next to the encrypted body and is not part of the encrypted payload. Do not put secrets in it.
- Sender, recipients and timing. Mail needs addresses and delivery information to travel, so these are visible to the servers that handle the message. Headers are not encrypted.
- Quoted text in replies, as noted above.
- A compromised device. If someone controls your unlocked browser or phone, they can read what you can read.
- A weak passphrase. The private key is stored on our server in encrypted form. Its strength depends on your passphrase, so choose a long one.
- The other person. The recipient can forward or copy what you send them.
We describe only the message body here. We make no claim in this post about other parts of a message.
Why this design#
Per-message keys keep the expensive RSA operation small and let one message go to many recipients. Storing the encrypted private key on the server lets you open your mail from any device without moving key files around, at the cost of making the passphrase the thing that matters.
For the setup steps, see the end-to-end encryption guide.