Securing Email: use GPG for all emails?

Question

I am thinking of using GPG to sign commits and particularly to secure emails, and have some questions regarding the usefulness.

---

Basic threat model

(I use LESP as abbreviation for large email service provider)

The data in transit may not be secure if the recipient isn't a LESP user. But that may be rare these days.

Most email data is TLS secured (over the wire) but non-secured at rest - if the service provider holds the private key or the data is not encrypted.

GMail does not seem to encrypt at rest or, if they do, tell much about it (do they have the private key? is it encrypted?). It is not in the transparency report, for example.

ProtonMail instead, uses e2e encryption and it is based in Switzerland. In ProtonMail, the private key is encrypted with a secure passphrase, hence if you lose it you lose access to the data, as it can not be decrypted any more (unless setting up recovery mechanisms).

I do not know though, whether they could store a plain text copy of the private key.

In any case, the emails to/from LESPs' users won't be secured at rest so I went ahead and create a GPG key. They would also need one to communicate both ways.

---

Question

• Does GMail or BESPs in general encrypt at rest and own the private key?
• Does ProtonMail store the encrypted PK in their server?
• Would using GPG for every email be paranoic?

Answer 1

I do not know the first 2 answers, Gmail or Pmail.

What I can tell you is that if you wish your messages to be safe is to always use PGP. That forces that you and the destination to have exchanged keys. Not always easy to do it and others might not understand how to do it. If you achieve this the message will be protected in transit and in rest in the mail server independently if the host does it or not. It will be even protected in your computer as you will need to enter the password for the certificate to decrypt it, if you wish so.

You will own your security and not be dependent on what third parties can or cannot do.

I also use PGP for my email for signing and when possible to encrypt it.

Answer 2

TL;DR

Your conflating a number of things related to public key cryptography (especially as implemented by OpenPGP as it applies to email), key escrow, data storage, and the way that SMTP works. That makes it hard to answer your question without challenging some of your underlying assumptions.

The ultra-short answer is that ProtonMail offers more privacy guarantees than Gmail, but nothing is perfect and no service can protect you against all possible threats. You need to review your threat model, and see which service most closely aligns with the password escrow concern that appears to be be your topmost concern.

Examine Your Threat Model: Gmail Isn't a Zero-Knowledge Platform

While Gmail supports S/MIME, and claims to support encryption at rest and in transit, your keys, key passwords, and certificates are essentially escrowed by Google's services if you use their native clients. In addition, any encryption applied to transit or at-rest data are owned and managed by Google, so your threat model should assume ab initio that Google always has access to any data and all metadata associated with your emails.

Even if you use a non-Google OpenPGP implementation, depending on the specific implementation details (e.g. whether you're using an in-browser editor or PGP implementation) you should still assume that Gmail has at least some of your message data and all of your metadata. These risks can be mitigated by using out-of-browser implementations, but the email metadata is still exposed because OpenPGP addresses message content rather than SMTP or TCP/IP metadata.

If Gmail, Google, or Alphabet are not potential threat actors in your model, then this may be fine. If they are potential threat actors or threat vectors, then you will want to look at other services that do not escrow keys, have zero-knowledge architectures that do not require trusting the email provider, and that have mechanisms in place to reduce metadata associated with same-provider delivery. Delivery to outside providers will always carry some residual risk for metadata, although the contents of the message can be secured against typical threat models.

Comparison to ProtonMail

Your original post mentions "PM," which one assumes here means ProtonMail. The ProtonMail platform addresses a different threat model and is based on a very different business model than Gmail or Google. The company also provides a lot of information about what is and is not encrypted under different scenarios.

The short summary is that ProtonMail does not escrow key passwords, but can't avoid providing metadata when passing emails outside of itself due to the nature of the SMTP protocol. They also store encrypted versions of your mail and private keys on their servers—although you could certainly use offline keys in the same way you might with another service too—but while this theoretically opens up a vector for brute force attacks against your escrowed keys or at-rest data, this is largely tinfoil hat territory assuming you have an uncompromised key with a strong password. It would be a lot easier to get your data another way rather than trying to simply seize and brute-force your encrypted server-side keys or data within an uncompromised zero-knowledge system.

Of course, barring injected backdoors into the web service or physical servers, ProtonMail could still be legally forced to share metadata about individual users (see the "Not Recommended" section of their threat model) such as IP logging. However, this primarily impacts metadata, not message data, so it's outside the scope of the question you're fundamentally asking regarding private key password escrow.

Their transparency report and warrant canary was last updated on 6 September 2021, so if password escrow is your primary concern then they better fit your threat model. However, if your concerns are different then you should certainly consider revising your threat model and control set to better account for whatever the real issue is.

Answer 3

Email is not an encrypted protocol, so you will forever be herding cats trying to make it into an encrypted protocol.

The purpose of end-to-end encryption tools is to protect the data against all intermediary communications tools because these tools cannot be trusted.

Proton, alone, does not accomplish the same protection as end-to-end encryption because they receive and send messages in the clear with other servers. While they claim that only you have the key to access the messages stored on the server, the messages at some point must be in plain text, which means you are trusting Proton and that defeats the purpose of end-to-end encryption.

A problem I discovered with using GPG for all messages is that you must publicly publish your public key. Shortly, you will begin receiving encrypted spam messages because the spammers know that very powerful spam prevention tools are at the server level, and the servers cannot read the contents of the message, so you are far more likely to open the message, thus bypassing the server spam protection tools. Or maybe I am the only one with this experience, but I doubt it.