Live data from Hacker News

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

efail.de

11–20 of 306 posts

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

#11
post #6

While HTTPS is taking over web traffic, encrypted email could be considered a failure, at this point. I wonder what percentage of emails are encrypted using GPG. Based on my experience it's probably less than 0.001%.

E-Mail needs better tools and better standards than GPG IMO.

For one, GPG tools are difficult to use. Anything beyond a simple 1-click-setup-ready-to-use-including-keyserver-publication will make any wide market adoption difficult.

On the other, the GPG standard is a bit ... clunky. Ideally it should be modernized to take advantage of the email format; add generic messages about encryption in alternate mime content bodies and simply encode the encrypted messages into it's own. I imagine other, similar, improvements could be made, up and including having GPG also sign the email headers before pushing it out into the world.

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

#12
post #7

So they gave up on the embargo or something? I thought it was supposed to be revealed tomorrow. It's for the best I suppose. I cringed a bit at the custom "efail.de" domain name though, that's so 2017.

They claim their embargo was "broken" [1]. Maybe by this tweet [2] from GnuPG trying to clarify in what way PGP/GPG are "vulnerable."

[1] https://twitter.com/seecurity/status/995964977461776385

[2] https://twitter.com/gnupg/status/995931083584757760

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

#13
post #6

While HTTPS is taking over web traffic, encrypted email could be considered a failure, at this point. I wonder what percentage of emails are encrypted using GPG. Based on my experience it's probably less than 0.001%.

As Let's Encrypt showed, this is all about usability.

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

#14
I see how this can be used to exfiltrate an email you’ve sent to others, but th exploit doesn’t seem to show how to exfiltrate private emails between other parties. I mean, it’s an interesting bug, but since the only I can exfiltrate is the contents of plaintext I sent you in the same exploit then it doesn’t seem to leak anything other than any HTML email does.

Am I missin something?

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

#15

I see how this can be used to exfiltrate an email you’ve sent to others, but th exploit doesn’t seem to show how to exfiltrate private emails between other parties. I mean, it’s an interesting bug, but since the only I can exfiltrate is the contents of plaintext I sent you in the same exploit then it doesn’t seem to leak anything other than any HTML email does. Am I missin something?

Sure. Assume you're a state-actor who wants to read someone's email. You can force their ISP to add code to their SMTP server that adds an efail-pixel jacket, but you can't force them to turn over the customer keys.

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

#16
post #9
post #6

While HTTPS is taking over web traffic, encrypted email could be considered a failure, at this point. I wonder what percentage of emails are encrypted using GPG. Based on my experience it's probably less than 0.001%.

PGP and HTTPS have very different trust models so it's comparing apples to oranges. That being said I agree that PGP failed to gain widespread adoption even though I personally use GnuPG daily and sign all of my emails. I'm still hoping that it'll make a comeback but I'm not holding my breath.

S/MIME uses a trust model similar to HTTPS, is built in to most clients and still has almost zero adoption.

I think the issue is that HTTPS is a pain in the ass for a few, while encrypted email is a pain in the ass for everyone. Between client cert distribution to wonky webmail support to escrow challenges for regulated orgs it requires deliberate effort for all parties forever.

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

#17
Tangent:

Is it just me or does CBC (and block ciphers in general) always seem to be a troublemaker? Even if it's not directly at fault, it seems to always make everything more difficult to secure, and I don't recall ever having heard of a single benefit gained by using them. Why do people insist on using block ciphers instead of stream ciphers? What benefits do they have?

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

#18
To be honest, this is a really bad joke. Not only did they chose to go directly to the media/EFF without even informing the GPG people but they also attacked them[1] for not keeping quiet. Not to mention all the fud that was spread for an issue that is not even caused by GPG but by bad clients (in fact I am not aware of any client that is vulnerable to this). Shame both to the publishers of this and to the EFF for helping the spread of the FUD without even consulting the GPG people.

[1]: https://twitter.com/seecurity/status/995936859980222464

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

#19

Tangent: Is it just me or does CBC (and block ciphers in general) always seem to be a troublemaker? Even if it's not directly at fault, it seems to always make everything more difficult to secure, and I don't recall ever having heard of a single benefit gained by using them. Why do people insist on using block ciphers instead of stream ciphers? What benefits do they have?

I heard once that people didn't like the regularity of the input of CTR mode. That might be why people back in the day preferred CBC.

These days, the big downside to stream-ciphers is nonce-reuse. It can be hard to guarantee each message has a separate nonce on e.g. embedded platforms.

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

#20
From what I've read, I thought that in modern cryptographic methods you always authenticate and encrypt, in part to avoid attacks like this where an attacker can modify the encrypted message in some way.

Does this mean that GnuPG and S/MIME don't authenticate/sign encrypted messages at all? Or that email clients still try to display encrypted messages that are not properly authenticated?

Post reply on HN