5 ms·

Am I missing something? I thought the PGP vulnerability wasn't in the Cryptography but the mail client rendering the HTML like a browser and allowing it to be o

Am I missing something? I thought the PGP vulnerability wasn't in the Cryptography but the mail client rendering the HTML like a browser and allowing it to be outgoing. Still a dumb move but fixable via going plain text everything. Granted the metadata and backlog issuss are themselves serious issues for the format. It is more a "stop using email even if encrypted" than "stop encrypting email".

paxys 7y ago
I think the overall advice is "stop using email for stuff you expect to be E2E encrypted". There are still valid use cases for "regular" email, and I'm okay with most of it hosted on Gmail and searchable etc.
- tptacek 7y ago
  A point you can make here that really upsets technologists is that organizations with real practical security concerns (for instance: most technology startups) can and do use the email infrastructure to have conversations that involve secrets --- but (1) almost none of them use encrypted email and (2) they rely heavily on GSuite for their security. And, for business-level secrets, this is usually fine! Better (more secure!) in fact, than the outcomes they'd get from trying to make the same workflow work with encrypted email! I feel like there is a kind of technologist whose head explodes when you tell them that links to GSuite documents are a safer workflow than PGP, but that is sometimes the case! This, of course, goes out the window when your threat model is extrajudicial.
  - paxys 7y ago
    Agreed, although change GSuite to Outlook. E2E encrypted email would be considered a security risk at every company I know, and in fact would be illegal in a lot of sectors. They want to use IRM etc. for encryption and access management but also want complete control of the keys.
  - BlueTemplar 7y ago
    Relying on GSuite is only "fine" for businesses located in the USA and that don't compete with Google. Otherwise it's an obvious security risk.
lvh 7y ago
There's not "one" PGP vuln: one of the things that makes PGP so pernicious is that it's a spec, a de facto implementation (GPG), an ecosystem used in different contexts (e.g. enterprise file transfer, but also e-mail) by completely different user archetypes. But yes, this post focuses on problems with email in general and why the problems are deeper than something solved with a "better PGP".
- jolmg 7y ago
  > one of the things that makes PGP so pernicious is that it's a spec, a de facto implementation, an ecosystem used in different contexts (e.g. enterprise file transfer, but also e-mail) Just like SSL/TLS and SSH? They're both specs via RFCs, they both have de facto implementations (openssl and openssh), and they're both used in different contexts (ssh can be used for file transfers, besides remote shells; TLS's applications are very broad like PGP's).
  - lvh 7y ago
    Great point! Sorry, I should have been clearer: the pernicious part is in _explaining how PGP and encrypted is bad_, which is a Herculean task because there's always another little use case broken in its own subtle way. TLS and SSH have that problem far less, because where they have issues (e.g. SSLv3, let's say), the issues are singular (e.g. the problem is that the obvious way to implement this introduces a padding oracle), not like GPG, where the issues are fractal (e.g. this isn't a real authenticator and consumers can be tricked in unauthenticated data -- a problem that requires a constellation of both GPG's broken crypto but also the specific context of e-mail and also a vulnerable client).
tptacek 7y ago
This claim about Efail is essentially false. Efail was possible because PGP uses an archaic message authentication scheme, one designed more or less before the dawn of authenticated encryption, which can be stripped off messages, and which is in a real sense an "add-on" as far as the core of PGP is concerned. PGP will release unauthenticated plaintext to its callers and count on them to check out-of-band errors to see that the plaintext isn't safe; mailers failed to reliably perform this check. There is a technical sense in which mailers are responsible for mitigating this vulnerability, but it's a vulnerability that can't exist in the first place in a well-designed cryptosystem. In the context of this post, this is basically a nit; the point the post makes is that even if you replace PGP with something like Age, encrypted email is still too risky to use, and is intrinsically inferior to modern secure messengers. (Encrypted email is not a use case Age is pursuing, and I do like Age).
- lvh 7y ago
  My only annotation here is that I think MDC was added in the early 2000s, after HMAC. My understanding is it's not so much that we hadn't figured out real authenticators, it's that the people designing PGP didn't believe in them or believed them unnecessary for some reason. You can see the echoes of this silliness in the description of MDCs in the RFC today, because of course RFCs are for pontification and not for spec description. (Grep RFC4880 for "NON-NORMATIVE EXPLANATION" if you're interested.)
- ubercow13 7y ago
  >PGP will release unauthenticated plaintext to its callers and count on them to check out-of-band errors to see that the plaintext isn't safe Is that problem the same as this one? https://github.com/FiloSottile/age/issues/59 https://github.com/FiloSottile/age/issues/59
  - tptacek 7y ago
    It is not, no. The problem we're talking about allows you to exfiltrate plaintext from messages you don't have the keys for, which you can do because PGP makes the ciphertext of messages malleable. This Age discussion pertains to entire messages that attackers construct from scratch under their own keys.

paxys 7y ago

I think the overall advice is "stop using email for stuff you expect to be E2E encrypted". There are still valid use cases for "regular" email, and I'm okay with most of it hosted on Gmail and searchable etc.

tptacek 7y ago
A point you can make here that really upsets technologists is that organizations with real practical security concerns (for instance: most technology startups) can and do use the email infrastructure to have conversations that involve secrets --- but (1) almost none of them use encrypted email and (2) they rely heavily on GSuite for their security. And, for business-level secrets, this is usually fine! Better (more secure!) in fact, than the outcomes they'd get from trying to make the same workflow work with encrypted email! I feel like there is a kind of technologist whose head explodes when you tell them that links to GSuite documents are a safer workflow than PGP, but that is sometimes the case! This, of course, goes out the window when your threat model is extrajudicial.
- paxys 7y ago
  Agreed, although change GSuite to Outlook. E2E encrypted email would be considered a security risk at every company I know, and in fact would be illegal in a lot of sectors. They want to use IRM etc. for encryption and access management but also want complete control of the keys.
- BlueTemplar 7y ago
  Relying on GSuite is only "fine" for businesses located in the USA and that don't compete with Google. Otherwise it's an obvious security risk.

lvh 7y ago

There's not "one" PGP vuln: one of the things that makes PGP so pernicious is that it's a spec, a de facto implementation (GPG), an ecosystem used in different contexts (e.g. enterprise file transfer, but also e-mail) by completely different user archetypes. But yes, this post focuses on problems with email in general and why the problems are deeper than something solved with a "better PGP".

jolmg 7y ago
> one of the things that makes PGP so pernicious is that it's a spec, a de facto implementation, an ecosystem used in different contexts (e.g. enterprise file transfer, but also e-mail) Just like SSL/TLS and SSH? They're both specs via RFCs, they both have de facto implementations (openssl and openssh), and they're both used in different contexts (ssh can be used for file transfers, besides remote shells; TLS's applications are very broad like PGP's).
- lvh 7y ago
  Great point! Sorry, I should have been clearer: the pernicious part is in _explaining how PGP and encrypted is bad_, which is a Herculean task because there's always another little use case broken in its own subtle way. TLS and SSH have that problem far less, because where they have issues (e.g. SSLv3, let's say), the issues are singular (e.g. the problem is that the obvious way to implement this introduces a padding oracle), not like GPG, where the issues are fractal (e.g. this isn't a real authenticator and consumers can be tricked in unauthenticated data -- a problem that requires a constellation of both GPG's broken crypto but also the specific context of e-mail and also a vulnerable client).

tptacek 7y ago

This claim about Efail is essentially false. Efail was possible because PGP uses an archaic message authentication scheme, one designed more or less before the dawn of authenticated encryption, which can be stripped off messages, and which is in a real sense an "add-on" as far as the core of PGP is concerned. PGP will release unauthenticated plaintext to its callers and count on them to check out-of-band errors to see that the plaintext isn't safe; mailers failed to reliably perform this check. There is a technical sense in which mailers are responsible for mitigating this vulnerability, but it's a vulnerability that can't exist in the first place in a well-designed cryptosystem. In the context of this post, this is basically a nit; the point the post makes is that even if you replace PGP with something like Age, encrypted email is still too risky to use, and is intrinsically inferior to modern secure messengers. (Encrypted email is not a use case Age is pursuing, and I do like Age).

lvh 7y ago
My only annotation here is that I think MDC was added in the early 2000s, after HMAC. My understanding is it's not so much that we hadn't figured out real authenticators, it's that the people designing PGP didn't believe in them or believed them unnecessary for some reason. You can see the echoes of this silliness in the description of MDCs in the RFC today, because of course RFCs are for pontification and not for spec description. (Grep RFC4880 for "NON-NORMATIVE EXPLANATION" if you're interested.)
ubercow13 7y ago
>PGP will release unauthenticated plaintext to its callers and count on them to check out-of-band errors to see that the plaintext isn't safe Is that problem the same as this one? https://github.com/FiloSottile/age/issues/59 https://github.com/FiloSottile/age/issues/59
- tptacek 7y ago
  It is not, no. The problem we're talking about allows you to exfiltrate plaintext from messages you don't have the keys for, which you can do because PGP makes the ciphertext of messages malleable. This Age discussion pertains to entire messages that attackers construct from scratch under their own keys.