EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME • Hacker News Board

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

#141

Post by shinigami » Mon, May 14, 2018, 3:46 PM UTC

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

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.

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

#142

Post by spacenick88 » Mon, May 14, 2018, 3:46 PM UTC

maxerickson wrote: post #48

tazjin wrote: post #10

This hardly seems like an OpenGPG or S/MIME vulnerability to me and more like an XSS-like exploit of email clients.

The encryption system should be saying "BAD MESSAGE" to the client and instead it is saying "Here's the message and some malware".

It really also just shouldn't support unauthenticated encryption at all. And with authenticated encryption I mean something like chacha20-poly1305 or AES-GCM that gives you authentication on small chunks so it can give the "BAD MESSAGE" output when decrypting from a pipe.

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

#143

Post by spacenick88 » Mon, May 14, 2018, 3:48 PM UTC

tazjin wrote: post #100

jerf wrote: post #96

Earlier quoted context omitted.

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…

> 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

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

#144

Post by tptacek » Mon, May 14, 2018, 3:49 PM UTC

LinuxBender wrote: post #135

baby wrote: post #104

Earlier quoted context omitted.

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

Is PGP broken? Or the plugins that make PGP easier to use email, that are rendering HTML, or those perhaps what is really broken?

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 is broken but we already knew that".

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

#145

Post by klez » Mon, May 14, 2018, 3:50 PM UTC

Xylakant wrote: post #129

klez wrote: post #98

Earlier quoted context omitted.

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

Afaics the attacker gets to pick the format.

I'll rephrase what I was trying to say:

If I'm expecting encrypted email, I don't expect it formatted as HTML, so I can just disable its rendering. At which point the attacker can send it any format they want, my mail client just won't render it.

The parent to my comment says this is unlikely, and I don't understand why. Hence my asking (and now I see I phrased it the opposite way).

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

#146

Post by spacenick88 » Mon, May 14, 2018, 3:52 PM UTC

noguespi wrote: post #58

A lot of buzz for a not so critical vulnerability. Well it is critical but very hard to exploit because : 1. Hacker need to intercept the encrypted email. 2. HTML tags/remote content are blocked by default on most email client. Still an important vulnerability, but not enough (for me) to disable enigmail, I know I'm safe with blocked remote content. By the way I hate this kind of "buzz" disclosure. Just disclose full…

Also in many (sensible) configurations the PGP key will be locked when not reading encrypted mails and will need a fresh password entry

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

#147

Post by floatboth » Mon, May 14, 2018, 3:57 PM UTC

A1kmm wrote: post #49

mkj wrote: post #38

Huh, PGP encrypted messages aren't authenticated? (No HMAC etc)

If I have your key, I can send you an encrypted GPG message, without you needing to know who am, or for any kind of message from you back to me. HMACs require a shared secret. GPG does optionally support signing, which provides for integrity for message contents, but it is optional, so is not a useful mitigation here. It supports a Modification Detection Code (MDC), which is just a hash of the message. In scenarios w…

> optional, so is not a useful mitigation here

Why in the heck does anyone ever send encrypted-only, non-signed messages?!?!

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

#148

Post by kbumsik » Mon, May 14, 2018, 3:58 PM UTC

> The EFAIL attacks require the attacker to have access to your S/MIME or PGP encrypted emails.

So the attacker needs to intercept email, but how they can access it?

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

#149

Post by codezero » Mon, May 14, 2018, 4:03 PM UTC

Has anyone seen a tool that will go through a mailbox and check for this attack? I'm really curious if anyone can find an example of this in the wild before publication.

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

#150

Post by LinuxBender » Mon, May 14, 2018, 4:07 PM UTC

tptacek wrote: post #144

LinuxBender wrote: post #135

Earlier quoted context omitted.

Is PGP broken? Or the plugins that make PGP easier to use email, that are rendering HTML, or those perhaps what is really broken?

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?