4 ms·

you are conflating PGP with PGP/MIME. The later is using PGP to encrypt mail. You can encrypt other things with PGP as well. But i kind of agree with your poin

you are conflating PGP with PGP/MIME. The later is using PGP to encrypt mail. You can encrypt other things with PGP as well. But i kind of agree with your point: a lot of the "original rant" the article answers to seems to be about its author preferring to use different tools over PGP, one of the relevant use case comparisons being communication where they put Signal vs PGP/MIME. Such a rant would not exist if PGP/MIME would not be a thing. There are other use cases mentioned in the rant, but this one seems to be the primary one. However its not that "pgp rides on email" it is that "email encryption rides on pgp". Yes, for the use case of communication email encryption has pitfalls that encrypted instant messengers like signal do not have, and at the moment the later is the better choice. But Signal has other pitfalls, like piggybacking on phone numbers or its saas architecture with a single commercially controlled point of failure. Email is so damn robust, we could not kill it even if we wanted to. I honestly do not get this whole "don't sign or encrypt email - use another app" idea. We live in a world where banks send five digit one time pins using unencrypted SMS and where Microsoft signs their security newsletter with PGP. The "if i don't see the need it should not exist" approach is egocentric, arrogant and naive. E-Mail exists, and it isn't going away anytime soon, so a cryptosystem for email is a necessity.

tialaramex 5y ago
Some of the "answers" are good rhetoric but bad technique. If you want to be reassured that the original rant is wrong, they're successful, and this is a prize-worthy debating tactic, but it's not useful for getting to the facts. The "answers" around MDC in particular suffer from this, they harp about how it is mentioned several times (it's a fatal problem, I think I'd mention it more than once) and you might get the impression that this means it's an invalid criticism, but notice that they carefully don't ever say so, because of course it is a fatal problem in the real world. If you dig further into the site their apology for MDC basically goes like this: If PGP had AE instead, we'd have the exact same UX and so it doesn't fix anything. Thus the problem is bad client software (weird, all the PGP software is bad, that doesn't seem like a coincidence). In fact the whole point of AEAD is that you can't build that UX. The problem is that the existing MDC handling gives back bogus plaintext and then just casually says "Also, the MDC was invalid" as if that wasn't the headline news. It behaves this way partly because MDC is optional, but also because PGP's developers don't understand that wrong is worse than failed. AE APIs just will not give you any plaintext at all when authentication fails, there is no authenticated plaintext. The result is that in PGP you can alter Bob's message "Police on high alert, act casual, wait for my next message" to read "Bring the whole shipment to the park at midnight tonight" and yes, the MDC fails and maybe Alice's client tells her there was a problem, but the message "Bring the whole shipment to the park at midnight" is still right there for Alice to act on anyway, and so guess what Alice is going to do...
- Jon_Lowtek 5y ago
  Your example seems overly dramatic to the point of being completely unbelievable. Can you provide some reference links or other further reading? How does an attacker change the complete text in a meaningful without knowing Bobs private key?
  - tialaramex 5y ago
    Essentially, all modern symmetric encryption works by XORing something an attacker can't know with the plaintext to form a ciphertext. The recipient does the reverse operation to turn ciphertext back into plaintext. So it's actually very simple to change what it says, without knowing the key, if you know what it says now. For example, XOR the old known message with your replacement to get a stream A, then you XOR the current ciphertext with A to get a new ciphertext, which will be decrypted to give your replacement message. [Edited: I re-read this and I've oversold it substantially. In practice you won't have this easy a time with a non-toy system. But some of the cipher modes PGP still routinely uses will make it almost this easy if the attacker knows what they're doing and has the entire message text] What a modern system does here is it uses an "Authenticated Encryption" mode where the ciphertext is slightly larger such that decrypting also ends up calculating a "tag" value that should match one carried in the message. If the message was altered that tag won't match, and crucially there just is no plaintext in this case. If you have a halfway modern web browser, the secured connection to Hacker News does exactly this, so an on-path attacker can't change anything going back and forth, the most they can do is blow up your connection. But nobody was doing that when PGP was originally invented. So at first what PGP does is it relies on digital signatures over the entire message. After processing the entire message apparently from Bob, PGP sees that it has a signature, and this signature fails - this isn't the message Bob signed. Bad guys (who know the message but not the keys) can't prevent that. But it turns out that in practice they needn't care. The (bogus) decrypted plaintext is shown to Alice first, and Alice will have likely seen messages with "failed" signatures before, and she knows it's probably some stupid mail server configuration issue or something else unimportant. This message from Bob decrypted as expected, so what's the problem? Now you know what the problem is, I explained it above, but Alice almost certainly doesn't, as you didn't when you replied. It seems crazy that an "encrypted" message could be altered so easily, who would design it that way? More modern versions of (Open)PGP introduce this thing called MDC, which makes it at least possible to think about whether this tampering has happened to the raw encryption, without signatures, however for ages the default behaviour was still to just warn the user that there's a problem after showing them the bogus plaintext. In current versions this isn't what will happen with raw GnuPG itself out of the box, except there are still lots of caveats (e.g. Unix pipes defeat this) and so in practical use you often end up back with the user being shown the bogus plaintext anyway.
anotherhue 5y ago
Firstly, thanks for your detailed reply. > However its not that "pgp rides on email" it is that "email encryption rides on pgp" Doesn't it go both ways though? The web-of-trust seems email focused, keyservers seem email focused. 'gpg --gen-key' straight up asks you to encode your email into the metadata. I guess bootstrapping on an existing network is always a pain point. What I was trying to highlight were the issues faced by 'partial adoption' of encryption, namely: A) It being cumbersome in the MUA and therefore likely to be ignored/disabled/complained about B) The myriad of ways for an OPSEC failure, or in common parlance, clicking the wrong button. If PGPMAIL or somesuch had eclipsed plain-old email, as Signal/WhatsApp have eclipsed SMS, then these issues could be resolved at the platform level.

tialaramex 5y ago

Some of the "answers" are good rhetoric but bad technique. If you want to be reassured that the original rant is wrong, they're successful, and this is a prize-worthy debating tactic, but it's not useful for getting to the facts. The "answers" around MDC in particular suffer from this, they harp about how it is mentioned several times (it's a fatal problem, I think I'd mention it more than once) and you might get the impression that this means it's an invalid criticism, but notice that they carefully don't ever say so, because of course it is a fatal problem in the real world. If you dig further into the site their apology for MDC basically goes like this: If PGP had AE instead, we'd have the exact same UX and so it doesn't fix anything. Thus the problem is bad client software (weird, all the PGP software is bad, that doesn't seem like a coincidence). In fact the whole point of AEAD is that you can't build that UX. The problem is that the existing MDC handling gives back bogus plaintext and then just casually says "Also, the MDC was invalid" as if that wasn't the headline news. It behaves this way partly because MDC is optional, but also because PGP's developers don't understand that wrong is worse than failed. AE APIs just will not give you any plaintext at all when authentication fails, there is no authenticated plaintext. The result is that in PGP you can alter Bob's message "Police on high alert, act casual, wait for my next message" to read "Bring the whole shipment to the park at midnight tonight" and yes, the MDC fails and maybe Alice's client tells her there was a problem, but the message "Bring the whole shipment to the park at midnight" is still right there for Alice to act on anyway, and so guess what Alice is going to do...

Jon_Lowtek 5y ago
Your example seems overly dramatic to the point of being completely unbelievable. Can you provide some reference links or other further reading? How does an attacker change the complete text in a meaningful without knowing Bobs private key?
- tialaramex 5y ago
  Essentially, all modern symmetric encryption works by XORing something an attacker can't know with the plaintext to form a ciphertext. The recipient does the reverse operation to turn ciphertext back into plaintext. So it's actually very simple to change what it says, without knowing the key, if you know what it says now. For example, XOR the old known message with your replacement to get a stream A, then you XOR the current ciphertext with A to get a new ciphertext, which will be decrypted to give your replacement message. [Edited: I re-read this and I've oversold it substantially. In practice you won't have this easy a time with a non-toy system. But some of the cipher modes PGP still routinely uses will make it almost this easy if the attacker knows what they're doing and has the entire message text] What a modern system does here is it uses an "Authenticated Encryption" mode where the ciphertext is slightly larger such that decrypting also ends up calculating a "tag" value that should match one carried in the message. If the message was altered that tag won't match, and crucially there just is no plaintext in this case. If you have a halfway modern web browser, the secured connection to Hacker News does exactly this, so an on-path attacker can't change anything going back and forth, the most they can do is blow up your connection. But nobody was doing that when PGP was originally invented. So at first what PGP does is it relies on digital signatures over the entire message. After processing the entire message apparently from Bob, PGP sees that it has a signature, and this signature fails - this isn't the message Bob signed. Bad guys (who know the message but not the keys) can't prevent that. But it turns out that in practice they needn't care. The (bogus) decrypted plaintext is shown to Alice first, and Alice will have likely seen messages with "failed" signatures before, and she knows it's probably some stupid mail server configuration issue or something else unimportant. This message from Bob decrypted as expected, so what's the problem? Now you know what the problem is, I explained it above, but Alice almost certainly doesn't, as you didn't when you replied. It seems crazy that an "encrypted" message could be altered so easily, who would design it that way? More modern versions of (Open)PGP introduce this thing called MDC, which makes it at least possible to think about whether this tampering has happened to the raw encryption, without signatures, however for ages the default behaviour was still to just warn the user that there's a problem after showing them the bogus plaintext. In current versions this isn't what will happen with raw GnuPG itself out of the box, except there are still lots of caveats (e.g. Unix pipes defeat this) and so in practical use you often end up back with the user being shown the bogus plaintext anyway.

anotherhue 5y ago

Firstly, thanks for your detailed reply. > However its not that "pgp rides on email" it is that "email encryption rides on pgp" Doesn't it go both ways though? The web-of-trust seems email focused, keyservers seem email focused. 'gpg --gen-key' straight up asks you to encode your email into the metadata. I guess bootstrapping on an existing network is always a pain point. What I was trying to highlight were the issues faced by 'partial adoption' of encryption, namely: A) It being cumbersome in the MUA and therefore likely to be ignored/disabled/complained about B) The myriad of ways for an OPSEC failure, or in common parlance, clicking the wrong button. If PGPMAIL or somesuch had eclipsed plain-old email, as Signal/WhatsApp have eclipsed SMS, then these issues could be resolved at the platform level.