story
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...
More discussion: https://articles.59.ca/doku.php?id=pgpfan:forward_secrecy
> 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?
I did a demonstration using GnuPG to provide a practical example:
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.
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.
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.
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.
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!
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.
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.
The word "hoary" means "grey-haired". "Stop Using Encrypted Email" was published in 2020; even in dog years, it's not "hoary".
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.
