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

101–110 of 306 posts

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

#101

Post by scandox »

baby wrote: post #71

Matt Green gave a pretty good summary of this: https://twitter.com/matthew_d_green/status/99598925414360678... Some of these thoughts are echoed by Filippo: > No, in 2018 you don’t get to claim the high ground and blame users and implementations if your crypto API returns the plaintext on a decryption error. from https://twitter.com/FiloSottile/status/996010161427935233 So yeah, most clients seem vulnerable but since…

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.

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

#102

Post by deong »

klez wrote: post #98
sambe wrote: post #78

Earlier quoted context omitted.

I'm reading this message with little context but it doesn't strike me as having reasons not to be worried. The two suggestions are: a) not to use HTML emails, which seems unlikely in practice; b) to use an obscure-sounding mode which has been implemented in such a way as to depend on the MUA doing multiple things correctly after the GPG code runs. What am I missing here? Is the latter mode on by default and MUA are w…

> not to use HTML emails, which seems unlikely in practice In a context where pgp is used, which is not me receiving promotional material or forwards from Grandma, why do you consider it unlikely that mail is to be sent as plaintext and not as html?

Almost every email client defaults to HTML. There are going to be people using both encryption and HTML.

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

#103

Post by maxerickson »

jerf wrote: post #96
maxerickson wrote: post #72

Earlier quoted context omitted.

Both things are problems. The encryption system should definitely be communicating that the message was tampered with...

Well, again, the encryption system will. Or at least it can. (Apparently you can encrypt without signing? WTF use is that? But let's assume signatures are used.) The MIME structure of email is the problem here. It isn't OpenPGP's problem to solve, which we know because there is literally no way for them to solve it. No conceivable (sensible[1]) update to OpenPGP could fix the problem, so it can't be their responsibil…

One of the attacks injects content into the encrypted messages.

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

#104

Post by baby »

scandox wrote: post #101
baby wrote: post #71

Matt Green gave a pretty good summary of this: https://twitter.com/matthew_d_green/status/99598925414360678... Some of these thoughts are echoed by Filippo: > No, in 2018 you don’t get to claim the high ground and blame users and implementations if your crypto API returns the plaintext on a decryption error. from https://twitter.com/FiloSottile/status/996010161427935233 So yeah, most clients seem vulnerable but since…

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?

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

#105

Post by deong »

gepeto42 wrote: post #97

Encryption plugins on top of other mail clients has always been a recipe for disaster. That being said, why would EFF tell people to completely uninstall it? When I hear that, I think "There is a crazy, in the wild, no user interaction needed remote code execution vulnerability". If someone had a use for PGP/GPG email (assuming they understand the threat model and the metadata that is not encrypted), surely they're b…

I believe the recommendation is to use something like Signal or iMessage -- an end-to-end encrypted channel that isn't email.

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

#106

Post by flatline »

jakobegger wrote: post #95
jcranmer wrote: post #85

Earlier quoted context omitted.

Thunderbird disables remote loading by default. It's vulnerable only if you take measures to override this, which is to say, you either: 1. Use movemail to receive email instead of IMAP or POP (there's an interesting vector to get your remote resources loaded by using movemail. If you read the code, you can probably guess it). 2. Enable remote loading for all senders by default. 3. Try to send an email with a sender…

Since the exploit depends on sending manipulated emails, I think that 3. and 4. are pretty easy, since it'll look like the email is from a trusted sender (and encrypted)

The encrypted messages will not be signed, unless the trusted sender is also the attacker or their key is compromised.

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

#107

Post by tptacek »

aepiepaey wrote: post #86
baby wrote: post #71

Matt Green gave a pretty good summary of this: https://twitter.com/matthew_d_green/status/99598925414360678... Some of these thoughts are echoed by Filippo: > No, in 2018 you don’t get to claim the high ground and blame users and implementations if your crypto API returns the plaintext on a decryption error. from https://twitter.com/FiloSottile/status/996010161427935233 So yeah, most clients seem vulnerable but since…

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

Yes. It has one job!

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

#108

Post by baby »

segmondy wrote: post #89
baby wrote: post #71

Matt Green gave a pretty good summary of this: https://twitter.com/matthew_d_green/status/99598925414360678... Some of these thoughts are echoed by Filippo: > No, in 2018 you don’t get to claim the high ground and blame users and implementations if your crypto API returns the plaintext on a decryption error. from https://twitter.com/FiloSottile/status/996010161427935233 So yeah, most clients seem vulnerable but since…

Just curious, why didn't you submit a patch?

I can't remember but I was probably too swamped back then, I should do it though.

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

#109

Post by Xylakant »

aepiepaey wrote: post #86
baby wrote: post #71

Matt Green gave a pretty good summary of this: https://twitter.com/matthew_d_green/status/99598925414360678... Some of these thoughts are echoed by Filippo: > No, in 2018 you don’t get to claim the high ground and blame users and implementations if your crypto API returns the plaintext on a decryption error. from https://twitter.com/FiloSottile/status/996010161427935233 So yeah, most clients seem vulnerable but since…

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

Aren’t modern ciphers checksummed and authenticated blockwise? If so, you could just abort the moment you see a broken block. Anything before that block would not be under the attackers control and harmless.

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

#110

Post by tptacek »

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.

This is the best crypto attack of the year. Anyone calling it "cringy clickbait" is saying more about themselves than about the work.
Post reply on HN