Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME

efail.de

Post reply on HN
Print view View original

231–240 of 306 posts

Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME

#231

Post by xorcist »

tptacek wrote: post #230
xorcist wrote: post #226

Earlier quoted context omitted.

> 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 st…

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

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.

Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME

#232

Post by tptacek »

xorcist wrote: post #231
tptacek wrote: post #230

Earlier quoted context omitted.

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

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.

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.

Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME

#233

Post by tptacek »

AnaniasAnanas wrote: post #222
tptacek wrote: post #212

Earlier quoted context omitted.

Yes, us head-in-the-clouds idealists with our pie-eyed demands that encrypted message protocols not leak the contents of our messages to anyone who can intercept them . What will we demand next, forward secrecy? We should climb down from our ivory towers.

> not leak the contents of our messages to anyone who can intercept them Already a thing, next? > forward secrecy There is https://tools.ietf.org/html/draft-brown-pgp-pfs-03 but to be honest forward secrecy in general does not make much sense in the context of email or backups.

Forward secrecy doesn't make sense in the context of email? Please, go on.

Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME

#234

Post by jwildeboer »

sp332 wrote: post #119
aepiepaey wrote: post #86

Earlier quoted context omitted.

So what would you expect GPG to do when invoked to operate on a pipe (rather than a file¹)? Buffer (possibly) gigabytes of decrypted data in memory, just to be able to discard it once DECRYPTION_FAILED is detected? ¹: where GPG does the right thing

Relevant comment from Werner Koch: https://twitter.com/FiloSottile/status/996011473112576000 Either GPG buffers the data and checks for DECRYPTION_FAILED, or the application depending on GPG does. Of the two options, it makes much more sense for GPG to handle this.

DECRYPTION_FAILED should always result with an empty return. Not with the decrypted content.

Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME

#236

Post by slrz »

sp332 wrote: post #119
aepiepaey wrote: post #86

Earlier quoted context omitted.

So what would you expect GPG to do when invoked to operate on a pipe (rather than a file¹)? Buffer (possibly) gigabytes of decrypted data in memory, just to be able to discard it once DECRYPTION_FAILED is detected? ¹: where GPG does the right thing

Relevant comment from Werner Koch: https://twitter.com/FiloSottile/status/996011473112576000 Either GPG buffers the data and checks for DECRYPTION_FAILED, or the application depending on GPG does. Of the two options, it makes much more sense for GPG to handle this.

The application is likely better equipped to do something reasonable if temporarily storing lots of data is in order.

Still, GnuPG could do the buffering automatically for small messages and force explicit configuration otherwise. The latter might not be realistically enforcable given the compatibility constraints.

Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME

#237

Post by jwildeboer »

tc wrote: post #138

Let's summarize the situation: Abstract: S/MIME and MUAs are broken. OpenPGP (with MDC) is not, but clients MUST check for GPG error codes. Use Mutt carefully or copy/paste into GPG for now. - Some mail clients concatenate all parts of a multipart message together, even joining partial HTML elements, allowing the decrypted plaintext of an OpenPGP or S/MIME encrypted part to be exfiltrated via an image tag. Mail clien…

“If GPG is asked to write the plaintext as a file, it will refuse. When the output is directed to a pipe, it will write the output and return an error code”

I honestly don’t care about the rationale, but this inconsistent behaviour is simply wrong. After 18 years of discussion, end this. Whenever DECRYPTION_FAIL occurs, there MUST be no decrypted content.

Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME

#238

Post by slrz »

Dylan16807 wrote: post #64
foo101 wrote: post #29

From the original article: > EFAIL describes vulnerabilities in the end-to-end encryption technologies OpenPGP and S/MIME that leak the plaintext of encrypted emails. I don't understand how this is being touted as vulnerabilities in OpenPGP and S/MIME. Sure there is undefined behavior in the OpenPGP and S/MIME standards but if implementations choose an insecure behavior for the undefined behavior, then it is a flaw i…

The use of CBC without proper authentication sounds like a flaw in the standard to me. Especially the line in the FAQ about being able to create a fresh valid signature for an altered ciphertext is not good.

The "create a fresh valid signature" part talks about creating a new signature with the attacker's identity. Sure, technically it's a valid signature but it won't fool anyone regarding the message's authenticity. This is trivially possible for all schemes where you can detach the signature from the message.

Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME

#239

Post by [deleted] »

kennell wrote: post #50

As if a brand name, logo and website were not enough, even the white paper title is cringy clickbait: "Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels". OpenPGP is not broken. Nothing in your paper has anything to do with OpenPGP. This is simply spreading overblown FUD for your 15 minutes of mainstream media fame.

[deleted]

Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME

#240

Post by smsm42 »

baby wrote: post #104
scandox wrote: post #101

Earlier quoted context omitted.

I think what people are saying is that this has been represented as an intrinsic flaw in PGP and that this may cause the media to basically say PGP is broken. I agree that this is significant because it affects many users and the potential effect is extremely negative. On the other hand if the headlines on this were more focused I think people on HN would not have reacted so negatively.

When almost all implementation of PGP are broken, can we say PGP is broken?

In this particular case, some implementations of one of the use cases are broken. This is completely incorrect to say PGP is broken as it implies all (or most) use cases and not only particular scenario.
Post reply on HN