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

131–140 of 306 posts

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

#131

Post by mschwaig »

mehrdadn wrote: post #22
rocqua wrote: post #19

Earlier quoted context omitted.

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.

How can embedded platforms generate IVs but face trouble generating nonces? Aren't IVs also nonces? Or do you mean a different aspect of it is the problem?

Both is an about euqally difficult problem, but modes that require a nonce fail much more spectacularly than modes that require an IV.

Typically with a re-used IV the same plain text will lead to the same cipher text, which can be an issue.

On the other hand with a re-used nonce you can basically recover the xor of two plain texts from two cipher texts. This leads to plain text very quickly and is a much more serious issue.

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

#132

Post by Sir_Cmpwn »

colemannugent wrote: post #118
Sir_Cmpwn wrote: post #56

Even setting aside that this is an excellent example of how toxic the security community is, the real problem here is that HTML email is a steaming pile of crap. The number of vulnerabilities introducted by the mind bogglingly stupid idea of putting HTML in emails is staggering. You're better off only reading plaintext emails and sending the rest to /dev/null. Bonus: this gets a good deal of spam out of your inbox!

Yeah, whoever thought that adding the attack/bug surface of a browser to the email client should be publicly shamed. I assume that aerc like mutt is not affected by this "vulnerability"?

Aye.

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

#133

Post by dmix »

Tyr42 wrote: post #125
colemannugent wrote: post #118

Earlier quoted context omitted.

Yeah, whoever thought that adding the attack/bug surface of a browser to the email client should be publicly shamed. I assume that aerc like mutt is not affected by this "vulnerability"?

Yeah, mutt is safe https://pbs.twimg.com/media/DdJ_d_wWsAEclUs.jpg:large

And the K-9 app seems safe which is the most popular way to use PGP on Android.

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

#134

Post by ComodoHacker »

baby wrote: post #104
scandox wrote: post #101

Earlier quoted context omitted.

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?

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

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

#135

Post by LinuxBender »

baby wrote: post #104
scandox wrote: post #101

Earlier quoted context omitted.

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?

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

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

#136

Post by dmix »

sambe wrote: post #78
patoh wrote: post #3

Earlier quoted context omitted.

Werner Koch goes into further detail at the start of the gnupg-users thread @ https://lists.gnupg.org/pipermail/gnupg-users/2018-May/06031...

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…

> a) not to use HTML emails, which seems unlikely in practice

I've always used plaintext when using PGP, same with others who have used it with me... I thought it was standard practice. I don't see the point in using HTML for one-on-one encrypted conversations. HTML is for newsletters and similar content. Although I assume this means "don't use HTML at all in your client, not just for encrypted email".

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

#137

Post by dangerface »

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…

No, in CURRENT_YEAR you don't get to not handle errors, and blame the api when theres errors.

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

#138

Post by tc »

Let's summarize the situation:

Abstract: S/MIME and MUAs are broken. OpenPGP (with MDC) is not, but clients MUST check for GPG error codes. Use Mutt carefully or copy/paste into GPG for now.

- Some mail clients concatenate all parts of a multipart message together, even joining partial HTML elements, allowing the decrypted plaintext of an OpenPGP or S/MIME encrypted part to be exfiltrated via an image tag. Mail clients shouldn't be doing this in any world, and can fix this straightforwardly.

- S/MIME (RFC 5751) does not provide for authenticated encryption, so the ciphertext is trivially malleable. An attacker can use a CBC gadget to add the image tag into the ciphertext itself. We can't expect a mail client to avoid exfiltrating the plaintext in this case. S/MIME itself needs to be fixed (or abandoned).

- OpenPGP (RFC 4880) provides for authenticated encryption (called "MDC", see sections 5.13 and 13.11 of the RFC) which would prevent a similar CFB-based gadget attack if enforced. GPG added this feature in 2000 or 2001. If the MDC tag is missing or invalid, GPG returns an error. If GPG is asked to write the plaintext as a file, it will refuse. When the output is directed to a pipe, it will write the output and return an error code [1]. An application such as an MUA using it in this manner must check for the error code before rendering or processing the result. It seems this requirement was not made clear enough to implementors. The mail clients need to release patches to check for this error. This will create an incompatibility with broken OpenPGP implementations that have not yet implemented MDC.

- Even without clients enforcing or checking the authentication tag, it's a bit trickier to pull off the attack against OpenPGP because the plaintext may be compressed before encryption. The authors were still able to pull it off a reasonable percentage of the time. Section 14 of RFC 4880 actually describes a much earlier attack which was complicated in this same manner; it caused the OpenPGP authors to declare decompression errors as security errors.

Net-net, using encrypted email with Mutt is safe [2, Table 4], though even there, opening HTML parts encrypted with S/MIME in a browser is not, and double-checking how it handles GPG errors would be prudent before forking a browser on any OpenPGP encrypted parts. See the paper for other unaffected clients, including Claws (as noted below) and K-9 Mail (which does not support S/MIME). Otherwise, it's probably best to copy and paste into GPG (check the error code or ask it to write to a file) until this is worked out.

[1] https://lists.gnupg.org/pipermail/gnupg-users/2018-May/06031...

[2] https://efail.de/efail-attack-paper.pdf

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

#139

Post by floatboth »

simias wrote: post #128
mtremsal wrote: post #67

Earlier quoted context omitted.

The comparison with amdflaws seems unfair. My understanding is that while they demonstrate a flaw in some email clients, it would be enough for an attacker to exploit one vulnerable target amongst the recipients to retrieve the plaintext email. Given that one cannot confirm whether others have taken appropriate steps, this vulnerability seems serious enough, no?

The amdflaws were real vulnerabilities too. The problem in both cases is that they messed up the disclosure so badly (in the case of amdflaws probably purposefully, here probably simply by mistake and maybe hubris) that you end up talking more about the disclosure than the problem itself. This one day "teaser" makes no sense from a security perspective, especially when it fails to actually tell you the proper way to…

amdflaws were "if you have admin access, you have admin access". This is "oh shit, mail clients / crypto plugins will stitch together '' and send your secrets to the attacker". Sounds much more serious.

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

#140

Post by digi_owl »

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.

The more news i read from _sec, the more they remind me of the cracking groups of the micro era...
Post reply on HN