Email Encryption with Sequoia PGP and Thunderbird

The Discord Face ID debacle has reminded me that centralized platforms routinely abuse user privacy. I can empathize with the desire to protect underage users, but requiring facial identification is overreach. It’s especially insulting when Discord leaked some 70,000 government IDs in October 2025 under similar pretenses.

While my friends and I scour the web for an alternative place to call our digital home, I finally gathered enough motivation to finish setting up end-to-end encrypted email (via Thunderbird and Sequoia PGP). If you’re curious about encrypted email, this post is for you.

Why encrypt email?

The first point to understand is that you don’t need a good reason to want encrypted email. Or encrypted anything, for that matter. FSF puts it nicely in their Email Self-Defense manual:

Bulk surveillance violates our fundamental rights and makes free speech risky. […] Even if you have nothing to hide, using encryption helps protect the privacy of people you communicate with, and makes life difficult for bulk surveillance systems.

I don’t have any particular need to send encrypted email. I do, however, believe that privacy is a fundamental right. Personal data should not be collected or monitored, no matter how innocuous. I want others who feel the same way to have an easy mechanism for communicating with me under those circumstances. In the realm of email, that’s PGP.

Generating OpenPGP keys with Sequoia PGP

Thunderbird is my email client of choice and offers a few different ways to set up end-to-end encryption (E2EE):

• Generate OpenPGP keys within Thunderbird directly
• Import OpenPGP keys generated from an external library (like Sequoia PGP or GnuPG)
• S/MIME certificates, which are out of the scope of this article

This article is about Sequoia PGP, so I obviously opted to import my keys instead of using Thunderbird OpenPGP.

Sequoia is not the only choice of PGP library. The most widely used library is GnuPG, venerable yet often criticized for its complexity and support for outdated algorithms. I recommend Sequoia because it promises to be safe by default and opinionated, two phrases that resonate with me.

Follow these steps to generate a PGP key with Sequoia and import it into Thunderbird.

Install Sequoia PGP:

brew install sequoia-sq

Generate your key:

sq key generate --profile rfc4880 --own-key \
  --name "Alice Example" --email alice@example.com

Note: although I included --profile rfc4880 in the command, it’s technically redundant since Sequoia uses RFC 4880 by default. I just wanted to reinforce that Thunderbird follows OpenPGP RFC 4880, not RFC 9580 published in 2024.

You can use sq key list to view the key you just generated. Take note of the topmost entry, which provides the 40-character fingerprint that you’ll use to identify your key in future steps.

If you’re like me and use a custom domain with multiple email aliases, you need to register each email alias to the PGP key you just generated. In PGP parlance, these aliases are called user ids. User ids are included in your key export, so it’s important you complete this step before importing your key into Thunderbird.

# Only do this if you have extra email addresses to add to your key
sq key userid add --cert $FINGERPRINT \
  --name Alice --email alice@work.example.com

Export your private key that you’ll later import into Thunderbird:

sq key export --cert $FINGERPRINT > secret.asc

Now open up Thunderbird, navigate to Account Settings > End-To-End Encryption, and import secret.asc via “Add key”. If you have multiple email addresses configured in Thunderbird, go to “Manage Identities” and configure E2EE for each one.

Key exchange

Now that you have E2EE enabled, it’s important to understand how that encryption actually works. Email encryption is only as good as the contacts you have that are also using PGP. If you’re exchanging email with someone not using PGP, your emails are plaintext regardless of your Thunderbird E2EE setup. PGP fundamentally requires an exchange of public keys between both participants in the conversation.

This necessity has lead to networks of public keys known as key servers, e.g. https://keys.openpgp.org/. These are effectively phone books mapping email addresses to verified public keys. You likely want to upload your own public key to one such server.

Within Thunderbird, you can discover public keys while composing an email via the OpenPGP Key Assistant. Alternatively, you can search with Sequoia:

sq network search alice@example.com

If Sequoia successfully locates a key, it follows up with a helpful message prompting you to verify the integrity of the key. The intent of this step is to verify with the participant that the certificate indeed belongs to them. Typically this happens via an alternative method of communication.¹

# I verify that this fingerprint belongs to Alice
sq pki link add --cert=$FINGERPRINT \
  --userid="Alice <alice@example.com>"

I won’t dive too far into the details, but the nature of key servers and key verification is widely known as the Web of Trust. It’s good practice to verify the keys of your PGP contacts because the act is effectively vouching for the authenticity of that key.

Updates to this post

A prior version of this post used GnuPG instead of Sequoia PGP, following the FSF guide Email Self-Defense. Since then, I’ve migrated to Sequoia PGP and use SSH instead of GPG to sign my git commits.

The reasons for this change have to do with my recent discovery of A schism in the OpenPGP world and its implications for PGP as a cryptographic standard. I plan to detail my thoughts on the subject in a future post, after I gather more research around the crazy world of PGP RFCs and the divergence of LibrePGP and OpenPGP.

I think it’s unfortunate that the already vanishingly small number of PGP users are further divided between the goal of backwards compatibility and modern cryptographic techniques. I tend to side with the authors of Sequoia PGP and their goal of a safe-by-default, opinionated implementation.