6 ms·

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

by md_ 5y ago

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.

upofadown 5y ago
>- PGP doesn’t give forward secrecy. 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 https://articles.59.ca/doku.php?id=pgpfan:forward_secrecy
- danShumway 5y ago
  > 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.
tzs 5y ago
> 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.
- md_ 5y ago
  Yeah, I think that’s fair. 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.
encryptluks2 5y ago
> 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.
- md_ 5y ago
  > 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!

by md_ 5y ago

upofadown 5y ago

>- PGP doesn’t give forward secrecy. 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 https://articles.59.ca/doku.php?id=pgpfan:forward_secrecy

danShumway 5y ago
> 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.

tzs 5y ago

> 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.

md_ 5y ago
Yeah, I think that’s fair. 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.

encryptluks2 5y ago

> 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.

md_ 5y ago
> 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!