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

121–130 of 306 posts

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

#121

Post by tptacek »

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?

IVs aren't nonces. Nonces need to be unique. IVs need to be unpredictable. Those are subtly different requirements.

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

#122

Post by bhhaskin »

tptacek wrote: post #110
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.

This is the best crypto attack of the year. Anyone calling it "cringy clickbait" is saying more about themselves than about the work.

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.

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

#123

Post by tptacek »

bhhaskin wrote: post #122
tptacek wrote: post #110

Earlier quoted context omitted.

This is the best crypto attack of the year. Anyone calling it "cringy clickbait" is saying more about themselves than about the work.

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.

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

#124

Post by acdha »

_bxg1 wrote: post #81

The fact that emails can contain images and active HTML has caused a slurry of security problems over the years. Let me tell you, if my emails were sensitive enough to require PGP, I would also use an email client which does not load images or evaluate HTML by default.

> Let me tell you, if my emails were sensitive enough to require PGP, I would also use an email client which does not load images or evaluate HTML by default.

This approach requires too much diligence for most cases: people will forget to switch to the encrypted system, they won’t have a key / it’s expired because they don’t use it regularly, the software will remain horrible because nobody uses it, etc. Encryption needs to be enabled and usable by default if you don’t want a regular stream of human error.

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

#125

Post by Tyr42 »

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

Yeah, mutt is safe

https://pbs.twimg.com/media/DdJ_d_wWsAEclUs.jpg:large

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

#126

Post by tptacek »

sp332 wrote: post #119
aepiepaey wrote: post #86

Earlier quoted context omitted.

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

Relevant comment from Werner Koch: https://twitter.com/FiloSottile/status/996011473112576000 Either GPG buffers the data and checks for DECRYPTION_FAILED, or the application depending on GPG does. Of the two options, it makes much more sense for GPG to handle this.

This is shades of the curl maintainer rationalizing CURL_SSL_VERIFYHOST=1 not doing any checking, because CURL_SSL_VERIFYHOST=2 does.

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

#128

Post by simias »

mtremsal wrote: post #67
simias wrote: post #55

Earlier quoted context omitted.

I don't even understand why they needed to tease the thing one day in advance with measures that were so weird that nobody knew what to expect. "Stop decrypting email", right, super convenient and totally appropriate given the actual vulnerability. Next time maybe they'll say "don't touch your mouse until further notice". What difference would it have made if they had simply published this website straight away? Seem…

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 mitigate the attack (no, "do not use PGP or S/MISE" is not a reasonable mitigation for people who actually rely on these technologies, especially when you can mitigate the attack by changing your settings or using a different client). Saying that PGP and S/MIME themselves are broken when it's mainly (but not entirely) a MUA problem is also rather disingenuous.

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

#129

Post by Xylakant »

klez wrote: post #98
sambe wrote: post #78

Earlier quoted context omitted.

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…

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

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

#130

Post by eigengrau »

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 might be prudent to have GnuPG return an error exit code instead of just printing a warning on stderr. Currently, it seems that clients (at least when using the shell interface) are supposed to parse the error stream. And even when they do (which many probably don’t), it’s not necessarily obvious that the presence of warnings indicates to the client that the data should not be used.
Post reply on HN