I think that’s the biggest problem, but there are others.
Off the top of my head:
- PGP key discovery is hard to do securely. Do you just trust what’s on the public keyserver? Do you use RFC 7929? S/MIME is relatively better in this respect, but obviously still quite behind the state of the art for e.g. Web PKI.
- PGP has so many different potential client configurations that it’s hard to reason about what security you are getting. Someone can (and for S/MIME, this is quite common!) have a PGP or S/MIME gateway that encrypts/decrypts mail to/from MUAs—meaning messages sit unencrypted in mailboxes and end user devices.
- PGP doesn’t encrypt metadata.
- PGP doesn’t give forward secrecy.
I’m sure there are other things I’m not thinking about, but for at least these reasons, PGP is in some ways less secure than SMTP TLS, hard to use correctly, and in general a lot of effort to leave you worse off than if you just chatted over WhatsApp/Signal/Wire/Threema/etc instead.
Transport layer security (and enforcing that) is definitely good for email, and we’ve moved the state of the art beyond where it was in the ‘70s, but I think the quest for true e2ee in SMTP-based email is probably not worth the effort.
Email should be thought of as having certain tradeoffs (like messages living unencrypted on servers, and relying fully on server to server trust), and for things that need e2ee, you should use something like Signal instead.
Generally, the value of forward secrecy in end to end encrypted messaging is proportional to the chance that the secret key material will be compromised. With an asynchronous, offline capable medium like encrypted email the secret key material can be protected very very well. A message archive accessible to the user for all practical purposes negates the value of forward secrecy. Most people like to keep their old emails around. Most people like to keep any form of messages around so that forward secrecy has little practical value in most forms of E2EE messaging.
There is no technical reason that you can't do forward secrecy for PGP. There is simply no real need for it. Encrypted email is more for the people that don't want their encrypted material compromised in the first place...
The other person replying already pointed out why this is an apples-to-oranges sort of argument, but for one specific point:
> There is no technical reason that you can't do forward secrecy for PGP. There is simply no real need for it.
Erm, I think there is such a reason--or at least, I can't imagine how you would implement PFS with PGP without substantially changing the usage. How would you do session key management a la https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm?
The entire premise of PGP seems to be that I can email you using just your long-lived key, without any other sort of session keying. That seems to fundamentally prevent PFS, no?
Forward secrecy is just forgetting the secret key material. The trick is the do it in a convenient way. In the case of something offline capable like OpenPGP over email, the inconvenience is in having to redistribute your keys before forgetting the secret key. You don't even have to reestablish any trust, that just works.
I did a demonstration using GnuPG to provide a practical example:
OMFG. This is the sort of thing that makes people not want to use PGP.
"It's totally easy to get PFS with PGP. You just have to read my 1000-word blog post about manually creating and distributing subkeys and be super careful you are editing the correct key before you proceed..." ;)
I suspect the answer you're looking for is that it's not necessary, but the much more likely reason is that the UX is horrible and it's error-prone, and even out of the few people who use PGP for this kind of stuff, a fairly sizable chunk of users probably don't even know what forward secrecy is. I would say the expectation that PGP users need to be informed enough about encryption to make a personal decision for themselves when to change their keys is itself a somewhat damning indictment of the PGP ecosystem. You shouldn't have to be an expert in this stuff to have good encryption.
Zooming out a bit, we could ask the same question that you've posed about email more broadly: why do most email users not bother with PGP encryption at all? Why do many client developers decide to not even add support to their apps?
If you take the perspective that lack of mainstream adoption of a security technique is evidence that the security technique has no value, then it's hard not to conclude that SMS and Facebook Messenger are both fine and we're all wasting our time with encrypted messaging of any kind. But my perspective is that people use more secure tools (in part) only once they're at least as accessible and usable as the other tools/platforms that they already have.
----
From your linked article:
> This process is very manual. There are no GnuPG --preburn and --burn commands to automate this. This suggests that this is not something that is commonly done. Most people don't fear the exposure of their keys enough to make this worthwhile for this sort of system.
PGP does not have a generally accessible, vetted way to automatically create those subkeys and distribute them that any non-technical (or even reasonably technical) user can take advantage of: if it did then the blogpost wouldn't exist. So of course people don't do that stuff, it's not surprising that people don't manually edit keys. The problem is when developers and proponents then respond to that by saying, "we don't need a generally accessible, vetted way to automatically create and distribute subkeys because people don't do that." Then the whole conversation starts getting really circular.
People use forward secrecy in Signal because it's on by default and works even if they don't know what forward secrecy is. Of course sometimes we can look at an ecosystem and we can take cues about user needs based on what they currently use. However, you have to be very careful about that. Don't fall into the same trap that (just as one example) Mozilla falls into, where they'll move an option into a buried preference menu and then say, "no one is clicking this anymore, guess we should remove it from the browser entirely." Sometimes users don't use features purely because they're not convenient, or accessible, or because they don't know the features exist.
It's also worth noting that broadly, most E2EE messaging platforms are moving towards forward secrecy, and PGP encrypted email is somewhat of an outcast in saying that forward secrecy doesn't matter. So it's not really like forward secrecy is easy everywhere and people go and turn it off because they don't need it. Increasingly, it's just older systems like PGP where people have decided not to approach messaging this way. I would posit the reason for that split is because PGP has bad UX for forward secrecy and most people using it or building around it know that doing unconventional things in PGP is a recipe for accidentally shooting yourself in the foot.
> This sort of attack could not reveal any messages archived off the network due to Signal's forward secrecy. Let's compare the end result to an encrypted email client running on the same phone using traditional passphrase protection [...] So the encrypted email actually ends up providing a better result for the user. That is because it is possible to lock up the encryption key more securely in practice with an offline medium than it is with an online, always available, medium like instant messaging.
I have some issues:
First off, you have no guarantee that anyone's client is storing PGP-encrypted mail only in its encrypted form, so you have no guarantee that anyone is actually required to input a passphrase every single time they want to look at their messages. In fact, I would wager that for many clients, this isn't the case, because I bet it makes functionality like local searching of messages a lot slower and more complicated.
Second, this isn't an argument about forward secrecy at all, it's an argument about putting an extra passphrase in front of logging into the messenger/client. There's a reason why Signal doesn't do that, and it's that it's really annoying and ordinary users turn it off. We have a hard enough time getting people to put locks on their phones, your model for email security on a phone can not be that someone is going to enter a full passphrase every time they check their email.
Third, if they're not on a phone most people don't use local email clients, they use the browser and access email on many devices, so I don't really buy the idea that email is mostly accessed offline. In fact, this is arguably one of the strengths of a platform like Signal; the fact that it requires downloading a client forces you to do a lot of stuff locally on the device.
Fourth, forward secrecy isn't necessarily about protecting the end-user's device anyway, it's about what happens when a key/archive gets compromised off-device. People sometimes try to dismiss that risk by saying that email gets sent over encrypted transports, but your email server can still be compromised or messages accessed using a warrant, and what forward secrecy can do is block an attacker from decrypting every message on the server or setting up a passive listener. This is a problem that's relevant to email because most users don't delete emails from the server after they're downloaded to a client -- most users rely on messages being stored in perpetuity on the server as well as on their clients.
Just to make this point more clearly:
> it is possible to lock up the encryption key more securely in practice with an offline medium than it is with an online, always available, medium like instant messaging.
Very few people use email the way you're describing. In practice, most people use email in the form of an always available, instant messaging service. Any security model for email that relies on people changing their behavior so drastically is (in my mind) not a particularly realistic or useful plan for mass encryption.
----
> Encrypted email is more for the people that don't want their encrypted material compromised in the first place...
Sure, but sometimes we do defense in depth, sometimes we think about what will happen if something gets compromised. The speed at which encrypted-email proponents jump to "just don't make any mistakes" is one of the reasons why I don't trust encrypted email. I don't think this is a conversation that acknowledges the ways that ordinary people use technology.
>First off, you have no guarantee that anyone's client is storing PGP-encrypted mail only in its encrypted form,...
No, that's how it works. Encrypted email stays encrypted until you decrypt it to look at it. I like to call this "encrypt once". People complain that they can't search their encrypted emails. You can make the user enter a passphrase to search (slow) or create an index and encrypt the index with the passphrase.
>...your model for email security on a phone can not be that someone is going to enter a full passphrase every time they check their email.
They are much more likely to do that than enter a passphrase to see if there is someone on instant messaging they would like to talk to. That is the distinction that is being made here. Asynchronous is inherently more secure than synchronous.
I think you have missed the points I made about forward secrecy and messaging. Neither depend on encryption of material on the network.
> Encrypted email stays encrypted until you decrypt it to look at it. I like to call this "encrypt once". People complain that they can't search their encrypted emails. You can make the user enter a passphrase to search (slow) or create an index and encrypt the index with the passphrase.
That doesn't have anything to do with whether it stays encrypted once it's sitting on the client device. You don't know that an email client isn't fetching the encrypted email, decrypting it, and then storing it in plain-text on the device. And there's nothing in the protocol that forces them not to do that.
You might want them to store contents encrypted on the client device, you might think it's best practice for them to do that, but you don't know that client will do that.
> They are much more likely to do that than enter a passphrase to see if there is someone on instant messaging they would like to talk to.
They're not going to do either of those things, it's like asking if I'm more likely to swim the Pacific or the Atlantic ocean. Neither scheme actually works in practice for a mass communication platform. People do not use email asynchronously, they treat it like long-form text in a messaging client, the same way they treat SMS or Signal or Element or whatever.
----
There's nothing special about email that means people are more likely to use a passphrase every time they want to access it on their phone. And even if they did (which they won't), there are risks other than client device access that forward-secrecy protects against. "On the network" in this case means that your encrypted emails are getting stored on a server that can be either compromised or accessed with a warrant. It is not true that the only way to gain access to E2EE archives is through the client device itself.
> PGP key discovery is hard to do securely. Do you just trust what’s on the public keyserver? Do you use RFC 7929?
In the case up above in this thread branch of the poster's bank not emailing statements because it is not secure, key discovery would be easy. The bank would have a form available only when logged in to their online banking site to enable statements by email with a way to upload your public key.
My guess is that for most people who could benefit from emailing encrypted documents it is similar. They have a good secure channel to give the other party their public key.
I'd rather that something better than PGP be used though.
As a nerd, it does seem to me like I should be able to give the bank a public key and let me worry about my own security. But I don’t think this is actually what the bank or the user wants—they don’t want encryption per se, they want authentication, and an HTTPS link in an email (that you have to login to view)
achieves that.
> PGP key discovery is hard to do securely. Do you just trust what’s on the public keyserver? Do you use RFC 7929? S/MIME is relatively better in this respect, but obviously still quite behind the state of the art for e.g. Web PKI.
That is what WKD is for and is already implemented by multiple providers.
> PGP has so many different potential client configurations that it’s hard to reason about what security you are getting. Someone can (and for S/MIME, this is quite common!) have a PGP or S/MIME gateway that encrypts/decrypts mail to/from MUAs—meaning messages sit unencrypted in mailboxes and end user devices.
Sounds like poor security if their client isn't doing the encryption, not an issue with encryption itself. Regardless, the point of encrypting email isn't to worry about what happens on the receivers end. If the receiver messes up then that is on them.
> PGP doesn’t encrypt metadata.
What metadata are you concerned about here? Subject lines? GPG is quite versatile so I'm not sure what metadata you are worried about.
> PGP doesn’t give forward secrecy.
Change your subkey then. Forward secrecy is more for real-time communication though, but if you want to generate a subkey to exchange a message then I'm sure it can be automated.
> I’m sure there are other things I’m not thinking about, but for at least these reasons, PGP is in some ways less secure than SMTP TLS, hard to use correctly, and in general a lot of effort to leave you worse off than if you just chatted over WhatsApp/Signal/Wire/Threema/etc instead.
I hear that a lot but I think the real issue is that users don't want to change anything and just want someone to do it for them.
> Sounds like poor security if their client isn't doing the encryption, not an issue with encryption itself. Regardless, the point of encrypting email isn't to worry about what happens on the receivers end. If the receiver messes up then that is on them.
Surely it’s on me, if I wanted the content to be secret?
> What metadata are you concerned about here? Subject lines?
I was mostly thinking subjects and traffic patterns itself. PGP trivially leaks both.
> Change your subkey then. Forward secrecy is more for real-time communication though, but if you want to generate a subkey to exchange a message then I'm sure it can be automated.
As I noted elsewhere in this thread, PFS doesn’t work for PGP’s normal usage model (without a lot of hassle, as you noted, with subkeys). I don’t think it’s that people don’t want PFS for asynchronous communication; it’s that email doesn’t make it easy to do.
> I hear that a lot but I think the real issue is that users don't want to change anything and just want someone to do it for them
I think that’s a fair characterization. But if you, as a software or product person, want to improve user security, the first thing you have to do is make usable secure products. PGP is almost never usably secure; it’s arguably not usable most of the time, and that’s doubly true when used securely!
> Sounds like poor security if their client isn't doing the encryption, not an issue with encryption itself. Regardless, the point of encrypting email isn't to worry about what happens on the receivers end. If the receiver messes up then that is on them.
No matter what encryption you use, if your recipient gets compromised there is nothing you can do except don't sign the message with a published public key and send the message anonymously. Then, at least, it would be more difficult to trace back to you unless you include personally identifiable information in the encrypted message.
> I was mostly thinking subjects and traffic patterns itself. PGP trivially leaks both.
First, when it comes to traffic patterns I have no clue what that means. You can hide the recipient with GPG, so they have some plausible deniability as long as someone else doesn't have their secret key and passphrase.
You can encrypt the subject line pending email client support to decrypt, but really it seems pointless. Might as well just say `hello` or `secure` in the subject line. I imagine you could also create an RFC to add an encrypted subject to the header if one doesn't exist already.
> As I noted elsewhere in this thread, PFS doesn’t work for PGP’s normal usage model (without a lot of hassle, as you noted, with subkeys). I don’t think it’s that people don’t want PFS for asynchronous communication; it’s that email doesn’t make it easy to do.
It doesn't have to be a lot of hassle. If I remember correctly, Keybase may have had something similar for messaging. It just hasn't been done because instead of using GPG, a lot of people want to implement something else, which is fine as long as it is secure. GPG is secure though which is why people throughout the intelligence community use it frequently and journalists that want security.
Maybe for PFS something like age makes more sense, but GPG has been around and is more tried and tested.
> think that’s a fair characterization. But if you, as a software or product person, want to improve user security, the first thing you have to do is make usable secure products. PGP is almost never usably secure; it’s arguably not usable most of the time, and that’s doubly true when used securely!
GPG is usable and usably secure, if you know even some of the basics of what you're doing. Really, just looking through the docs on GPG's website provides a vast resource of information. It can be overwhelming for grandma, and yes sometimes the docs are confusing in certain areas, but it is not challenging for people in tech that have a little patience (doesn't require a lot).
There certainly isn't anything stopping GPG from being the default except competing solutions. It has been pretty much the default for email security for some time.
It feels like you’re arguing that, technically, GPG _can_ be used to achieve the same level of security as modern messaging platforms. That’s probably true. (I say “probably” because I’m not a cryptographer, so I’m not qualified to speak to the cipher algorithms used.)
My claim was never that, though. My claim is that in the “normal” usage of PGP, it’s substantially less secure than modern alternatives, and that this is a mostly inherent byproduct of the use cases for which PGP appears to be constructed.
Succinctly: it’s hard to use PGP securely.
Can you do it? Probably. Could PGP be the default if everyone gave up on the easier to use, more secure alternatives? Well, on this point I am skeptical: before Signal, Wire, Threema, WhatsApp, etc—some of us remember those days!—the “default” was plaintext email. Not PGP.
PGP had 30 years to become the norm. During the first twenty or so, it had no real competitors other than S/MIME. And, here we are.
There are a lot of areas—fountain pens, for example, or vintage sports cars—where old technology has its own appeal, but encrypted communications isn’t one of them.
The subject line is message text! It's message! That's literally what it is! It's baffling (and revealing) to see email encryption advocates downplay the fact that subjects are exposed in plaintext. The retcon here is that subjects are somehow intended as the unencrypted, public part of the message, as if that was a normal feature of a sealed letter. Go find the last letter you mailed someone (or try to remember; I know it's been awhile) and look on the envelope for the part where you wrote what the message was about.
I explained ways to avoid this. Write `secure` for the subject and include the actual subject in the encrypted message. Propose an RFC to include an encrypted subject in the headers. Encrypted the subject line. I don't think this is valid considering that there are solutions.
When you're at the point of making excuses for important parts of the message text being revealed in plaintext, the useful debate about email encryption is basically over.
What if instead of writing “secure” in the subject, I just don’t send the email and instead use Signal or WhatsApp where all the text is encrypted end to end?
It’s not clear why it’s desirable to keep bolting things onto email in an attempt to somehow make it eventually match the security profile that we can already get by just using other existing options.
In any sufficiently long discussion of PGP’s merits, it becomes obvious that those arguing for PGP are not motivated by a desire to keep communications confidential, but, rather, to justify use of PGP.
Not going to rehash what other people are writing about PGP, that could be a much longer conversation. But it's not just PGP that's the problem, PGP just happens to be what people are using to encrypt email.
If it was just PGP that was the problem, we'd use something else to encrypt our emails and it would be fine. But the problem is that any system that works like PGP where we're primarily encrypting message contents, where we're not thinking about stuff like forward secrecy -- that's not good for email. Email itself isn't good for that because email doesn't really lend itself to E2EE, regardless of what you use to do the encrypting and key validation.
So you could have a version of PGP that was amazing and brilliant, and it still wouldn't really be a good fit for encrypting email, because email is not a good fit for encrypting email. The entire structure of how email works makes it difficult to do encryption in a user-friendly, accessible way.
I am also pretty skeptical of PGP (see some of the other comments), but that's not specifically why I mentioned it in my original comment. I only brought it up because most email encryption schemes I see are using PGP, and I don't think that PGP miraculously solves the problem. It's not good enough to paper over the fundamental flaws in email itself.
You also have a lot of weird cryptographic beliefs, like "authenticated encryption is a misfeature for tools like PGP, because unauthenticated ciphertext helps with data recovery", or "GPGME definitely doesn't just execute the GPG binary in order to perform PGP operations", or "forward secrecy is overrated because people keep all their old messages around" (also: "people should keep all their old messages around"). People that also believe these weird things will find your canned reply convincing. Cryptography engineers generally will not.
The word "hoary" means "grey-haired". "Stop Using Encrypted Email" was published in 2020; even in dog years, it's not "hoary".
I think most people complaining about GPG just don't want to be bothered with figuring anything out. They'd rather input their phone number into some cloud app that says it is secure and feel more secure than actually be bothered with understanding security in the first place.
I’ve spent a decade working in the industry, most of it unwinding complex infrastructure and codebases. I don’t hate GPG because I can’t be bothered to figure it out. I understand it and it’s bad at handling the problems it claims to solve.
I really don't have time to go through every item in the biased article, but you can hide recipients, you can use Ed25519. Seriously, if I was influenced by every blog post I read then I would probably be using Windows 7 still and trusting everything Gartner says.
It seems a bit rude to ask me for examples, have me provide one, and then just shrug it off that you don’t have time to address the items.
“You can use ed25519” kindof flies in the face of the point being made in the post, which is that sure, you can use modern crypto, but you’re bounded by the lowest common denominator, and GPG’s lowest common denominator is horrible broken crypto selections.
