4 ms·

PGP as an ecosystem has always suffered from toolbox-itis: when a tool (especially a cryptographic tool) tries to be everything, it ends up doing nothing partic

PGP as an ecosystem has always suffered from toolbox-itis: when a tool (especially a cryptographic tool) tries to be everything, it ends up doing nothing particularly well. This got ossified in the form of OpenPGP, and has basically remained the status quo for the last ~25 years. More generally, the OpenPGP world is in a bit of a double-bind: they can either fix things by breaking compatibility (at which point someone can reasonably observe that there's no good reason not to ditch OpenPGP entirely), or retain compatibility and accept that OpenPGP will never get much better than RFC 4880 and whatever smattering of drafts the GnuPG maintainers agree to implement. One way essentially results in an entirely different tool/standard that happens to be wearing PGP's skin; the other means keeping around misuse-prone and outright broken cryptographic primitives (and bad formats to boot). (To answer your actual question: email is just a bad substrate for attempting E2EE messaging. Latacora has a great explainer post on why[1]. TOFU is a mostly adjacent concern; trust/identity negotiation is hard, but the thing that makes WhatsApp, Signal, etc. actually work is that they eliminate manual key management and make cryptographic right choices for the user, rather than expecting the user to hold the tool correctly. In other words: they're misuse-resistant, where PGP as an ecosystem has historically not been.) [1]: https://www.latacora.com/blog/2020/02/19/stop-using-encrypted/ https://www.latacora.com/blog/2020/02/19/stop-using-encrypte...

tcfhgj 3y ago
they arent miss-use resistant when it comes to mitm attacks
- woodruffw 3y ago
  Neither Signal nor WhatsApp is MITM-able. Could you explain why you think they are? (Signal and WhatsApp also have forward secrecy properties that PGP, as an ecosystem, is nowhere close to providing. PGP very much still operates under the "one master key that you must never ever lose or disclose" paradigm.)
  - matheusmoreira 3y ago
    They are trivially MITM-able. Not long ago there was news posted here that telecom employees are selling SIM swaps. There's your MITM vulnerability. People can pay to impersonate others by taking over their phone numbers and consequently their messenger accounts. This attack will be noticeable: there will be a message warning the user that the cryptographic keys have changed on the other end. You know what else generates these warnings? Reinstalling WhatsApp, switching phones... They're basically noise to users by now due to alarm fatigue. How many users even know what that this key stuff means anyway? How many people even use the built-in key verification function which consists of just scanning a QR code? I've yet to meet a single person who cares about any of this stuff.
  - deleted 3y ago
    [deleted]
  - sowbug 3y ago
    My guess is that the term "MITM" is being overfit to include the basic problem of verifying that A's identity really belongs to A rather than M.
    - 7bit 3y ago
      But you can verify the other end. Not wanting so so that ist Not a Problem of the App or protocol.
  - 01HNNWZ0MV43FF 3y ago
    It's hard to prove the whole chain of possibly-tampered hardware and proprietary software hasn't gotten any malicious update to steal private keys at any point
    - woodruffw 3y ago
      If your threat actor is omnipotent, you’re going to have a very hard time designing a coherent threat model against them. Neither Signal nor PGP nor hiding under the bedsheets will protect you from an adversary capable of directly recording your screen. (But note: absent something like that, it in fact is possible for Signal to prove that you’re communicating with the same identity you initiated with. That’s the whole point of authenticated key agreement, which is not something that PGP can natively perform.)
kaiengert 3y ago
there is a response here: https://articles.59.ca/doku.php?id=pgpfan:tpp https://articles.59.ca/doku.php?id=pgpfan:tpp
- woodruffw 3y ago
  I’ve read this response before, and I don’t think it’s great: it makes claims about time-testedness and simplicity that on first glance apply to PGP, but in reality are either outright wrong (the results against MDC instead of true AEAD are in, and it’s a fail) or misleading in their conclusions (a “simple” packet structure that encourages EXPTIME parsing is not actually simple). The assumption underlying much of the post is that PGP is only used in offline, stateless applications. This would make the arguments stronger, except that it isn’t true[1]. [1]: https://delta.chat/en/ https://delta.chat/en/
  - upofadown 3y ago
    >...the results against MDC instead of true AEAD are in, and it’s a fail... It's really OCFB-MDC. It's only a authenticated mode when the two things are used together (like GCM). It doesn't provide protection of associated data (the AD part of AEAD) but that isn't something that seems to be potentially useful for the stuff that the OpenPGP standard is used for. I don't know what "true AEAD" means in this context. As a user I only care that the OCFB-MDC mode is actually secure. I am not interested in any philosophical aspects. The stuff about offline stateless applications only adds to the argument. A version of OCFB-MDC could be used, for say, TLS and would be expected to be secure.
    - woodruffw 3y ago
      > It doesn't provide protection of associated data (the AD part of AEAD) but that isn't something that seems to be potentially useful for the stuff that the OpenPGP standard is used for. It isn't sensible to assert this, because people use OpenPGP in all kinds of crazy ways. One of the recurring headaches in applied cryptographic engineering is discovering that people do, in fact, attempt to use PGP for instant messaging (per above), as a TLS certificate delivery mechanism, etc. These are contexts where the use of an AEAD is frequently appropriate. > As a user I only care that the OCFB-MDC mode is actually secure. In practice, it has not been[1]. PGP's decision to use MDC instead of a real MAC is a classic example of home-rolled primitives being conceptually algebraically sound but broken in user settings. The solution here is simple: OpenPGP is not special, and should use a MAC or AEAD mode like everyone else does. It also shouldn't release the plaintext until the authentication tag is actually validated, which was another profound historic breakage with MDC. [1]: https://mailarchive.ietf.org/arch/msg/openpgp/w4i30aLplh91iw6RuE1-kWdg26w/ https://mailarchive.ietf.org/arch/msg/openpgp/w4i30aLplh91iw...

tcfhgj 3y ago

they arent miss-use resistant when it comes to mitm attacks

woodruffw 3y ago
Neither Signal nor WhatsApp is MITM-able. Could you explain why you think they are? (Signal and WhatsApp also have forward secrecy properties that PGP, as an ecosystem, is nowhere close to providing. PGP very much still operates under the "one master key that you must never ever lose or disclose" paradigm.)
- matheusmoreira 3y ago
  They are trivially MITM-able. Not long ago there was news posted here that telecom employees are selling SIM swaps. There's your MITM vulnerability. People can pay to impersonate others by taking over their phone numbers and consequently their messenger accounts. This attack will be noticeable: there will be a message warning the user that the cryptographic keys have changed on the other end. You know what else generates these warnings? Reinstalling WhatsApp, switching phones... They're basically noise to users by now due to alarm fatigue. How many users even know what that this key stuff means anyway? How many people even use the built-in key verification function which consists of just scanning a QR code? I've yet to meet a single person who cares about any of this stuff.
- deleted 3y ago
  [deleted]
- sowbug 3y ago
  My guess is that the term "MITM" is being overfit to include the basic problem of verifying that A's identity really belongs to A rather than M.
  - 7bit 3y ago
    But you can verify the other end. Not wanting so so that ist Not a Problem of the App or protocol.
- 01HNNWZ0MV43FF 3y ago
  It's hard to prove the whole chain of possibly-tampered hardware and proprietary software hasn't gotten any malicious update to steal private keys at any point
  - woodruffw 3y ago
    If your threat actor is omnipotent, you’re going to have a very hard time designing a coherent threat model against them. Neither Signal nor PGP nor hiding under the bedsheets will protect you from an adversary capable of directly recording your screen. (But note: absent something like that, it in fact is possible for Signal to prove that you’re communicating with the same identity you initiated with. That’s the whole point of authenticated key agreement, which is not something that PGP can natively perform.)

kaiengert 3y ago

there is a response here: https://articles.59.ca/doku.php?id=pgpfan:tpp https://articles.59.ca/doku.php?id=pgpfan:tpp

woodruffw 3y ago
I’ve read this response before, and I don’t think it’s great: it makes claims about time-testedness and simplicity that on first glance apply to PGP, but in reality are either outright wrong (the results against MDC instead of true AEAD are in, and it’s a fail) or misleading in their conclusions (a “simple” packet structure that encourages EXPTIME parsing is not actually simple). The assumption underlying much of the post is that PGP is only used in offline, stateless applications. This would make the arguments stronger, except that it isn’t true[1]. [1]: https://delta.chat/en/ https://delta.chat/en/
- upofadown 3y ago
  >...the results against MDC instead of true AEAD are in, and it’s a fail... It's really OCFB-MDC. It's only a authenticated mode when the two things are used together (like GCM). It doesn't provide protection of associated data (the AD part of AEAD) but that isn't something that seems to be potentially useful for the stuff that the OpenPGP standard is used for. I don't know what "true AEAD" means in this context. As a user I only care that the OCFB-MDC mode is actually secure. I am not interested in any philosophical aspects. The stuff about offline stateless applications only adds to the argument. A version of OCFB-MDC could be used, for say, TLS and would be expected to be secure.
  - woodruffw 3y ago
    > It doesn't provide protection of associated data (the AD part of AEAD) but that isn't something that seems to be potentially useful for the stuff that the OpenPGP standard is used for. It isn't sensible to assert this, because people use OpenPGP in all kinds of crazy ways. One of the recurring headaches in applied cryptographic engineering is discovering that people do, in fact, attempt to use PGP for instant messaging (per above), as a TLS certificate delivery mechanism, etc. These are contexts where the use of an AEAD is frequently appropriate. > As a user I only care that the OCFB-MDC mode is actually secure. In practice, it has not been[1]. PGP's decision to use MDC instead of a real MAC is a classic example of home-rolled primitives being conceptually algebraically sound but broken in user settings. The solution here is simple: OpenPGP is not special, and should use a MAC or AEAD mode like everyone else does. It also shouldn't release the plaintext until the authentication tag is actually validated, which was another profound historic breakage with MDC. [1]: https://mailarchive.ietf.org/arch/msg/openpgp/w4i30aLplh91iw6RuE1-kWdg26w/ https://mailarchive.ietf.org/arch/msg/openpgp/w4i30aLplh91iw...