3 ms·

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

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

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!

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