142 lines
13 KiB
Markdown
142 lines
13 KiB
Markdown
---
|
||
title: "Sending End‑to‑End Encrypted Email (E2EE) without losing friends"
|
||
date: 2025-10-30
|
||
draft: false
|
||
tags: ["privacy", "email", "e2ee", "proton", "tuta", "pgp", "s/mime", "gmail cse"]
|
||
categories: ["Privacy"]
|
||
summary: "A practical, mildly opinionated guide to sending encrypted email that normal people can actually read."
|
||
ShowToc: true
|
||
TocOpen: true
|
||
---
|
||
|
||
If you’ve ever thought “I should really send this **securely**” and then immediately remembered key servers, certificate stores, and that one time you bricked your GPG setup, this post is for you. Below is a **usable** path to end‑to‑end encrypted email, roughly how each option works, and when to use which—sprinkled with a little fun so your eyes don’t glaze over.
|
||
|
||
> Honestly, I don't know why one would settle down for a paid option, but if you want to, then be my guest.
|
||
|
||
## Why people *don’t* use E2EE email (and why you still should)
|
||
|
||
Email wasn’t designed for secrecy. It leaks metadata (who emailed whom and when), search and spam engines expect to read your messages, and traditional E2EE requires exchanging and trusting keys or certificates—things most people never think about. That creates friction, breaks “just works” expectations, and makes onboarding your accountant, landlord, and cousin Maddie… exciting.
|
||
|
||
But the **upsides** are huge: true confidentiality of message content and attachments, stronger **authenticity** (signatures!), compliance wins for sensitive data, and fewer “oops, wrong inbox” disasters haunting you forever. In short: if it matters enough to **hesitate** before sending, it probably matters enough to encrypt.
|
||
|
||
I mean, generally speaking one can use e2ee for anything, and not just email, but doesn't it feel cool if you sign your mail with your key, and if the receiver also has pgp keys, to send e2ee mail? No one knows what the two of you talk about, well unless there is a back door in your machine, buuuuuuuut assuming not, you're good to go!
|
||
|
||
## The contenders (and how they feel to use)
|
||
|
||
### Proton Mail (consumer‑friendly, great cross‑provider story)
|
||
Proton gives you automatic E2EE between Proton users. When you email someone on Gmail or Outlook, you can send a **password‑protected message** that opens in a secure web page; you share the password out‑of‑band (SMS, Signal, etc.). If your recipient already uses PGP, Proton can speak that too. Day‑to‑day, it’s just email—with an extra “lock” option when you need it.
|
||
|
||
**Prices (personal):** Free tier exists; paid tiers like **Mail Plus** and **Proton Unlimited** add storage, custom domains, and Proton Bridge for desktop clients. Expect **single‑digit € per month** for personal use; business plans are per‑user.
|
||
**How to use:** Sign up → compose → choose password‑protected email for non‑Proton recipients or send normally to Proton addresses. Recipients can **reply securely** in the web portal—even without an account.
|
||
**Ups:** Lowest friction to message non‑tech people; slick apps; plays well with PGP if you’re a power user.
|
||
**Downs:** Metadata like recipients stays visible across the wider email network; full power (Bridge, larger storage) lives behind paid tiers.
|
||
|
||
Honestly though, although I love proton and want to work for them, idk why you would want to pay for such services. If you use their other options, like custom mail domains, etc., then be my guest, otherwise just use Thunderbird! It's easy to use, and fun to show off.
|
||
|
||
### Tuta (formerly Tutanota) (privacy maximalist, subject‑line encryption)
|
||
Tuta offers automatic E2EE between Tuta users and **password‑protected emails** to anyone else. Its special sauce: it encrypts more by default in its ecosystem—including **subject lines**—and the whole suite is open‑source and auditable.
|
||
|
||
**Prices (personal & business):** Free plan plus personal tiers (e.g., **Revolutionary**, **Legend**) and business tiers (**Essential/Advanced/Unlimited**). Personal is typically **low single‑digit €/month**; business is **per‑user, per‑month**.
|
||
**How to use:** Create an account → compose → set a password for non‑Tuta recipients; they read and reply in a secure web page.
|
||
**Ups:** Max privacy posture; encrypted subjects between Tuta users; clean apps.
|
||
**Downs:** Some advanced mail protocols/features are intentionally limited; cross‑ecosystem mail still exposes standard email metadata.
|
||
|
||
I was introduced to this one literally for writing this post, I had no idea it existed before.
|
||
|
||
### Gmail with **Client‑Side Encryption** (CSE) (for organizations on Google Workspace)
|
||
If you live in Google Workspace, CSE brings real end‑to‑end encryption to Gmail—**keys stay with your organization**. After admins set it up, users toggle encryption right in the compose window. It’s the least disruptive path for big teams that already run on Gmail.
|
||
|
||
**Prices:** CSE is available on certain Workspace editions (e.g., **Enterprise Plus**, **Education Standard/Plus**, **Frontline Plus**). No extra per‑message fee, but you’ll need a compliant key service and the right subscription tier.
|
||
**How to use:** Ask IT to enable CSE and your key service → compose in Gmail → turn on encryption for messages that need it.
|
||
**Ups:** Seamless for employees; centralized key control; good audit/compliance story.
|
||
**Downs:** Only for supported Workspace tiers; external recipients may need compatible tooling or a secure portal experience; not for personal @gmail.com accounts.
|
||
|
||
I mean... how much can you trust google and their non-open source client? I know some of my collegues here do use it, I won't. Not with the emails that matter to me.
|
||
|
||
### Outlook / Apple Mail with **S/MIME** (classic enterprise path)
|
||
S/MIME uses **X.509 certificates** instead of PGP keys and is deeply integrated into Outlook and Apple Mail. Inside one company (or between partners who exchange certs), it’s smooth sailing. Your IT can deploy certificates automatically so users never touch crypto knobs.
|
||
|
||
**Prices:** The tech is built in; costs come from **certificates**. Orgs often issue them internally; public CA prices vary.
|
||
**How to use:** Install/auto‑deploy your certificate → recipients share theirs → click encrypt/sign in Outlook or Mail.
|
||
**Ups:** Great inside enterprises; MDM‑friendly; widely supported.
|
||
**Downs:** Exchanging certs across companies is clunky; personal certs can be confusing; mixed ecosystems require coordination.
|
||
|
||
Ok. Is there that big of a difference between these and Gmail? Idk. I ain't trusting non of it. But maybe the apple client I do partially trust. They seem to care about user privacy, or maybe they have brain washed me to believe so.
|
||
|
||
### Thunderbird + OpenPGP (free, powerful, nerd‑approved—now usable)
|
||
Thunderbird bakes in **OpenPGP** and S/MIME. You generate or import a key once, and Thunderbird remembers which contacts can be encrypted. It even supports **protected headers/subject encryption** so the visible subject can be replaced with a stub while the real subject lives inside the encrypted part. For many privacy‑minded folks, this is the sweet spot of control and usability.
|
||
|
||
**Prices:** Free.
|
||
**How to use:** Install Thunderbird → create/import a PGP key → hit the little lock when writing to someone whose key you have. Done.
|
||
**Ups:** Full control, open source, works with any provider via IMAP/SMTP; subject protection available.
|
||
**Downs:** Initial key exchange still scares people; you may need to hand‑hold contacts through setup the first time.
|
||
|
||
This is just the best. You can also have your calendars at one place. Also your contacts and everything else. They don't have iOS app which sucks, idk about Android.
|
||
|
||
### Browser add‑ons: Mailvelope & FlowCrypt (bring E2EE to webmail)
|
||
If you’re welded to webmail, add‑ons can meet you where you live. **Mailvelope** brings OpenPGP to Gmail/Outlook/Yahoo and more, right in the browser. **FlowCrypt** focuses on a polished PGP experience for Gmail and Google Workspace, with business features and key management options.
|
||
|
||
**Prices:** Mailvelope is free/open‑source. FlowCrypt has a generous free tier with **paid enterprise features** for teams.
|
||
**How to use:** Install the extension → create/import keys → compose in a secure editor injected into your webmail.
|
||
**Ups:** Zero provider switch; good for gradually introducing encryption to a contact list that lives in Gmail.
|
||
**Downs:** Browser crypto UX still has edges; enterprise key policy needs the paid tiers; fewer bells & whistles than a full desktop client.
|
||
|
||
Just no. Don't trust add-ons. Please.
|
||
|
||
## So… which should *you* use?
|
||
|
||
If you need to send a one‑off encrypted message to a **non‑technical person**, Proton or Tuta’s **password‑protected email** is the friendliest: they click a link, enter the password you shared elsewhere, and can **reply securely** even without an account. For a **company already on Google Workspace**, turn on **Gmail CSE** so people don’t juggle keys. If you’re a **power user** or want provider‑agnostic control, go with **Thunderbird OpenPGP**—it’s free, modern, and interoperable. And if you won’t leave the web, try **Mailvelope** or **FlowCrypt** to bolt E2EE onto the inbox you already use.
|
||
|
||
Honestly though, I would suggest thunderbird all day everyday, twice on Sunday. But that is just my view. If you fancy something else, well go ahead.
|
||
|
||
## A note on what E2EE hides (and what it doesn’t)
|
||
|
||
End‑to‑end encryption protects the **body** and **attachments**. Across the wider email network, **metadata like From/To and delivery timestamps** remain visible by design. Subjects may also be visible unless your tools use **protected headers** (Thunderbird can; Tuta encrypts subjects inside its ecosystem). If you truly need to hide *everything*, email might not be the right tool—reach for Signal or Matrix instead.
|
||
|
||
## Quick price & fit-at-a-glance
|
||
|
||
| Option | Best fit | Personal price vibe | Notes |
|
||
|---|---|---|---|
|
||
| Proton Mail | Everyday private email + easy messages to anyone | Free; personal paid tiers in **single‑digit €/mo**; business per‑user | Password‑protected emails to non‑Proton; PGP support |
|
||
| Tuta | Privacy‑max email; encrypted subjects in‑ecosystem | Free; personal low **€/mo**; business per‑user | Password‑protected emails to non‑Tuta; open source |
|
||
| Gmail CSE | Orgs on Google Workspace | Included with **Enterprise Plus/Education/Frontline** editions | Admin setup + external‑recipient flow |
|
||
| S/MIME (Outlook/Apple Mail) | Enterprises with IT/MDM | Software built‑in; **cert costs vary** | Smooth inside one org; cert exchange needed across orgs |
|
||
| Thunderbird OpenPGP | Provider‑agnostic power users | Free | Can encrypt subjects via protected headers |
|
||
| Mailvelope / FlowCrypt | Must stay on webmail | Free / **paid enterprise** options | PGP in the browser; good stepping stone |
|
||
|
||
## The 60‑second starter packs
|
||
|
||
**Proton/Tuta for one‑offs:** create an account, write your message, set a password, send; share the password over Signal or SMS. Recipient opens the secure link and can reply—no account needed.
|
||
|
||
**Thunderbird for everything else:** install, make a key, send your first signed message; when your contact replies with their key, hit the lock and enjoy encrypted bliss.
|
||
|
||
---
|
||
|
||
## **Shower thoughts**
|
||
|
||
So, why did I mention any of this?
|
||
Aside from the fact that I do believe e2ee email should become defacto, and I don't know why it isn't already, I do think we are not taking any steps toward protecting ourselves, and rely on third parties to do so for us.
|
||
|
||
A while ago when the 12 day war happened in Iran, they eventually allowed domestic platforms to be used by Iranians living abroad to talk to their loved ones back home.
|
||
The thing is, people might not use them because they don't trust them.
|
||
|
||
The question I had was different.
|
||
Assuming that the service is reliable, why can't we use it and protect ourselves while doing so?
|
||
|
||
In hindsight this seems stupid.
|
||
But listen to me.
|
||
If you have a wrapper that uses your gpg key to encrypt your messages, then you send them via those seemingly "untrusted" medium, why wouldn't you be able to use it?
|
||
The only, and oh well, biggest problem is key exchange.
|
||
Now to be honest, there exist key repositories that one can use, but also you can publish your public key over github, or any open verifiable medium. It is not foolproof, but it's a way.
|
||
And as long as there is a minimum reliable channel between the two parties, they can verify the authenticity of the key.
|
||
Like via a quick short call.
|
||
They can also be faked, but let's not go that extreme.
|
||
Also if many do it, it's hard to screw over all of them, maybe a subset with spending much resources, but no way you can screw everyone.
|
||
|
||
Idk how stupid the thing I'm suggesting is, but I wonder if it can be done or not. I don't know if I'm willing to spend my free time on it or not, but I though I should share the idea to at least know if it's stupid and wrong or not.
|
||
|
||
|
||
|
||
---
|
||
|
||
{{< sigdl >}}
|