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

171–180 of 306 posts

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

#171

Post by rocqua »

Xylakant wrote: post #117
tptacek wrote: post #114

Earlier quoted context omitted.

Modern AE schemes are designed to make it easy to quickly abort the whole decryption operation as soon as an error is detected. But the PGP protocol is from the 1990s, and uses vanilla CBC or CFB and then tacks the SHA-1 hash of the plaintext to the end of the message in a separate record.

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.

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

#172

Post by Natanael_L »

xoa wrote: post #160
tptacek wrote: post #144

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. The MAC of a PGP message is the SHA-1 of its plaintext appended to the message. There are coherent ways to downplay today's announcement, but "PGP isn't broken" isn't one of them. The best you can do is "PGP…

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

It does exist, but has approximately zero users

https://saltpack.org/

No PFS, though

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

#173

Post by tptacek »

rocqua wrote: post #170
tptacek wrote: post #161

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.

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 email to deliver secrets.

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

#174

Post by dane-pgp »

spacenick88 wrote: post #143
tazjin wrote: post #100

Earlier quoted context omitted.

> Apparently you can encrypt without signing? WTF use is that? Sending a message without identifying the author, for example.

Which can be achieved with authenticated encryption by generating a new key and deleting it afterwards

Is there a standard for this? It seems like if you tried to do it by hand, the receiver's UI would present this in a scary/confusing way. I'm imagining instead some sort of "Alan Smithee" User ID which the UI interprets as "deliberately anonymous/disavowable".

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

#175

Post by rocqua »

tptacek wrote: post #123
bhhaskin wrote: post #122

Earlier quoted context omitted.

But it isn't a crypto attack at all. Gpg is doing what it is supposed to do, and the overall cryptography is not effected. It's bad clients that are the problem.

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.

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

#176

Post by Natanael_L »

LinuxBender wrote: post #150
tptacek wrote: post #144

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. The MAC of a PGP message is the SHA-1 of its plaintext appended to the message. There are coherent ways to downplay today's announcement, but "PGP isn't broken" isn't one of them. The best you can do is "PGP…

What would be the most sensible steps forward for the PGP maintainers? Is this a rewrite, or can they iterate though and make incremental improvements around the flaws that have been discussed over the past decade?

A bit of both. We can fix a few bits in compatible ways, but it's not a reliable long term solution.

Long term, we really need an upgrade that breaks compatibility with old unfixable clients

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

#177

Post by Natanael_L »

ComodoHacker wrote: post #134
baby wrote: post #104

Earlier quoted context omitted.

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

But in MOV SS/POP SS case we don't say Intel chips are broken, we fix the OSes and the docs.

Why not both? Documentation can also be faulty

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

#178

Post by Natanael_L »

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. Show me the right message or nothing at all.

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

#179

Post by jwilk »

testcross wrote: post #83

Even protonmail says the authors were not responsible by letting EFF communicating so strongly... https://mobile.twitter.com/ProtonMail/status/996006094605570...

Non-mobile link:

https://twitter.com/ProtonMail/status/996006094605570048

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

#180

Post by rocqua »

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…

This isn't undefined behavior. This is malleability. Attackers get to change some parts of the plain text without needing to know the encryption key.

This is very much an issue with the S/MIME standard, which has no defence against this kind of attack. For PGP it is slightly different, as there is a defense against it (the 'MDC', a sha-1 hash of the plaintext) but it has a soft-fail if the MDC is not present.

Both are issues with the standard. For S/MIME it is a total failure, whilst for PGP the failure is mitigated slightly by an obscure and non-urgent error message. But, it is unreasonable to expect users to act on this kind of error message. Really, what you want here is a hard fail, but that would break backwards compatibility.

Post reply on HN