4 ms·

> If you strip the SHA-1 hash off a message, GPG will print a warning. That's far from the whole story. If you strip off the authentication, GPG will fail with

> If you strip the SHA-1 hash off a message, GPG will print a warning. That's far from the whole story. If you strip off the authentication, GPG will fail with an error. Not a warning message. (Over a socket, gpg will have started sending real data before failing, due to a bad and ancient design. OpenPGP can improve here, so let's point out the real problems instead of making up simpler ones for the sake of a good story.) If your mail client supports encrypted email silently ignoring errors there's going to be more attacks possible than this one. And if you're parsing untrusted HTML with Outlook 2007, well, that might be problematic in itself. I don't think anyone is dismissing the attack itself, but the communication around it could have been a little better. Most use of GPG takes place outside of MUAs.

tptacek 9y ago
GPG provides unauthenticated plaintext to callers. It needs to stop. There's not much more to discuss.
- xorcist 9y ago
  Nobody is arguing against that, so there's really no one to convince. What's being argued against are statements like "gpg doesn't fail on unauthenticated messages", and "stop using gpg with email" where the former just isn't true and the latter isn't very helpful seeing how the vast majority of gpg usage is things like git workflows which are completely unaffected by this.
  - tptacek 9y ago
    Everybody who argues that clients should be more careful checking warning messages and error codes and therefore this isn't a GPG problem is in fact arguing that.
    - cyphar 9y ago
      I don't see why we shouldn't hold clients accountable for not checking error codes from a cryptographic tool. Would you have the same opinion if a client didn't check the error code of 'gpg --verify' -- and thus accepted all signed messages as being valid? I think it's fair to say that there is more than one issue at play here. FWIW, I completely agree that AEAD should have been added to PGP a long time ago and it's asinine that it hasn't been done yet. Not to mention that it's vulnerable to surreptitious forwarding, and the packet format is insanely complicated and has lots of edge-cases that mean that everyone has to emulate GPG in order to work properly. These things concerned me so much that I decided to use ChaCha20-Poly1305 instead of PGP for a recent project. (I was skeptical of this vulnerability when I first read it, but after sleeping on it and reading comments like yours I decided I was mistaken -- especially since .)
    - xorcist 8y ago
      You are being very confrontative for no apparent reason. Arguing that mail clients should not hide decryption errors from users is not "in fact" arguing that gpg should keep leaving plaintext fragments around on errors. Far from it. But it does not matter how perfect encryption tool you can design if your mail client displays a signature as valid when it is in fact not valid. If you have constructive opinions on how gpg implements AEAD constructs then why not take them to the mailing list? There are plenty of know-it-all personalities in the open source community, but Werner is not one of them.
      - tptacek 8y ago
        Speaking of that: https://www.benthamsgaze.org/2018/05/15/tampering-with-openpgp-digitally-signed-messages-by-exploiting-multi-part-messages/ https://www.benthamsgaze.org/2018/05/15/tampering-with-openp...

tptacek 9y ago

GPG provides unauthenticated plaintext to callers. It needs to stop. There's not much more to discuss.

xorcist 9y ago
Nobody is arguing against that, so there's really no one to convince. What's being argued against are statements like "gpg doesn't fail on unauthenticated messages", and "stop using gpg with email" where the former just isn't true and the latter isn't very helpful seeing how the vast majority of gpg usage is things like git workflows which are completely unaffected by this.
- tptacek 9y ago
  Everybody who argues that clients should be more careful checking warning messages and error codes and therefore this isn't a GPG problem is in fact arguing that.
  - cyphar 9y ago
    I don't see why we shouldn't hold clients accountable for not checking error codes from a cryptographic tool. Would you have the same opinion if a client didn't check the error code of 'gpg --verify' -- and thus accepted all signed messages as being valid? I think it's fair to say that there is more than one issue at play here. FWIW, I completely agree that AEAD should have been added to PGP a long time ago and it's asinine that it hasn't been done yet. Not to mention that it's vulnerable to surreptitious forwarding, and the packet format is insanely complicated and has lots of edge-cases that mean that everyone has to emulate GPG in order to work properly. These things concerned me so much that I decided to use ChaCha20-Poly1305 instead of PGP for a recent project. (I was skeptical of this vulnerability when I first read it, but after sleeping on it and reading comments like yours I decided I was mistaken -- especially since .)
  - xorcist 8y ago
    You are being very confrontative for no apparent reason. Arguing that mail clients should not hide decryption errors from users is not "in fact" arguing that gpg should keep leaving plaintext fragments around on errors. Far from it. But it does not matter how perfect encryption tool you can design if your mail client displays a signature as valid when it is in fact not valid. If you have constructive opinions on how gpg implements AEAD constructs then why not take them to the mailing list? There are plenty of know-it-all personalities in the open source community, but Werner is not one of them.
    - tptacek 8y ago
      Speaking of that: https://www.benthamsgaze.org/2018/05/15/tampering-with-openpgp-digitally-signed-messages-by-exploiting-multi-part-messages/ https://www.benthamsgaze.org/2018/05/15/tampering-with-openp...