Live data from Hacker News

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

efail.de

181–190 of 306 posts

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

#181

One more reason to stop using html emails people...

People would be more secure if the web didn't use HTML too (or certainly if it didn't have JavaScript), but trying to convince users not to like features of their software has never been a very productive security strategy.

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

#182
post #160

Earlier quoted context omitted.

> Pretty much the whole cryptography field has been saying PGP is broken for something close to a decade now; the attack published today is an applied refinement of theoretical tools we've had for a very long time. Yes. But unless I've missed something no one has bothered to even attempt any modernized, improved replacement, so we continue to muddle along. I've certainly heard complaints about existing secure email t…

No, contrary to what you're saying, virtually all the work done in retail cryptography over the last several years has been in secure messaging. Don't send secrets over email; use a cryptographically secure messaging application, like Signal or Wire.

>No, contrary to what you're saying, virtually all the work done in retail cryptography over the last several years has been in secure messaging.

That is not contrary to what I'm saying, that is exactly what I'm saying. Much of the world, both corporate and private, do not want "messaging", they want "email". I use scare quotes for the latter because I want to distinguish between email as in existing technical standards dating all the way back to RFC 561 and email as-in that kind of information transfer service and format, distinct from messaging. Messaging has its place too, but there is clearly a desire for an electronic version of sending a piece of mail. It fits human and cultural psychology. It produces a different kind of consideration and formatting, which has both its merits and demerits. But messaging is not a replacement for email. You can insist that it is but I don't think you will be successful, and you should know better then most that security which isn't used isn't useful security.

>Don't send secrets over email

Back here on Planet Earth sending all sorts of secrets over email and using it for authentication of incredibly important accounts is the regrettable rule, not the exception. Like use of passwords. It is the reality in which we live. I see no sign of it changing either unless there is a direct in-place upgrade available. Which there is not.

>replace email with this thing that requires a phone number and is not like email

No.

>replace email with this thing that didn't even bother to add e2e crypto until 2016, claims to be agpl/gplv3 but then adds a bunch of other random crap on top, etc. Also not email.

No.

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

#183

Earlier quoted context omitted.

It should split it in chunks and authenticate each one of them. Then the worst attack would be the ability to truncate the file, and it could be at least detected. Unfortunately this is not supported by the PGP spec, or any other well established spec.

What's happened here is that GPG has used the OpenPGP spec as excuse to support extremely insecure default behavior. In reality, GPG can simply buffer and check before writing to stdout, and, in the rare cases where messages are too large to buffer, a flag can be used to override the secure default.

If the message is too large to buffer, one might also first just decrypt and stream the plaintext into sha-1.

Once the MDC clears, you can just decrypt again, this time writing to stdout.

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

#184
post #175

Earlier quoted context omitted.

It strips the PGP MDC and then uses a malleability attack on CFB or CBC to inject content, but it's not a crypto attack? You have a definition of "crypto attack" that nobody in the field uses.

To be fair, a very large part of this attack is not about PGP at all. That part is about abusing email-client rendering of partly encrypted messages, and abusing S/MIME to get message malleability again exploited via HTML.

Again, this is like saying that BEAST isn't really about TLS, because you need a particular combination of client features to exploit it. The two attacks are almost exactly analogous in this respect. But PGP has a cheering section, and TLS doesn't.

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

#185

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?

It's not block ciphers versus stream ciphers. CFB mode is a stream cipher and is implicated in this attack. CTR, the canonical stream cipher, is even more malleable than CBC. The problem is authenticated versus non-authenticated ciphers. CBC, CTR, and CFB are non-authenticated cipher designs. EAX, GCM, and OCB are authenticated designs.

Thank you!!

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

#186
post #182

Earlier quoted context omitted.

No, contrary to what you're saying, virtually all the work done in retail cryptography over the last several years has been in secure messaging. Don't send secrets over email; use a cryptographically secure messaging application, like Signal or Wire.

> No, contrary to what you're saying, virtually all the work done in retail cryptography over the last several years has been in secure messaging. That is not contrary to what I'm saying, that is exactly what I'm saying. Much of the world, both corporate and private, do not want "messaging", they want "email". I use scare quotes for the latter because I want to distinguish between email as in existing technical stand…

The problem with emails is that you have to deal with a thousand different clients implementing things differently. There is no win there.

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

#187

Earlier quoted context omitted.

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.

Does Thunderbird verify that the message is signed before displaying images from a whitelisted sender?

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

#188
post #171

Earlier quoted context omitted.

So the reasonable answer for me would be “go forth and use a modern scheme by default.”

The issue there is that if you call something PGP, people expect backwards compatibility, but if you switch to a different mode of encryption that becomes a massive pain.

Good old SSH managed to update ciphers. This is certainly easier if Server and client can negotiate, but it’s not impossible for GPG. You could start by adding better modes as an option, later make them default and ask for confirmation when decrypting an old message format. If I read the vulnerability description correctly, it allows stripping the message authentication signature and then trick the client into decoding it. So any message sent with a modern cipher or just requiring message authentication by default would have substantially mitigated the attack.

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

#189
post #170

Earlier quoted context omitted.

It woulds still be great to get some sort of protocol that will work over email. This is still the de-facto way of communication. If we can secure it, it would be a massive win. Much like the wide-spread use of HTTPS over HTTP was a massive win.

Why would that be a good thing? You'd still be left with a system that leaks immense amounts of metadata, which is often all government adversaries really care about, where the majority of the installed base isn't encrypted and you have to interoperate, and the vast majority of users gets access to messages through a web browser and so is hamstrung on secure delivery of encryption in the first place. Just stop using…

I think the GP's desire is not email per se, but rather an open and federated protocol like email so we aren't dependent on a single commercial vendor. I'm not really sure how practical that is since it's really hard to get broad adoption of a new protocol on today's internet.

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

#190
post #160

Earlier quoted context omitted.

> Pretty much the whole cryptography field has been saying PGP is broken for something close to a decade now; the attack published today is an applied refinement of theoretical tools we've had for a very long time. Yes. But unless I've missed something no one has bothered to even attempt any modernized, improved replacement, so we continue to muddle along. I've certainly heard complaints about existing secure email t…

No, contrary to what you're saying, virtually all the work done in retail cryptography over the last several years has been in secure messaging. Don't send secrets over email; use a cryptographically secure messaging application, like Signal or Wire.

Not ready to recommend Riot/Matrix?
Post reply on HN