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

111–120 of 306 posts

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

#111

Post by spacenick88 »

mehrdadn wrote: post #17

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?

I think the really broken thing is not using authenticated encryption ever. In 2018 no one should be using a non-authenticated cipher for anything except teaching about bad ideas.

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

#112

Post by tptacek »

AnaniasAnanas wrote: post #21
AnaniasAnanas wrote: post #18

To be honest, this is a really bad joke. Not only did they chose to go directly to the media/EFF without even informing the GPG people but they also attacked them[1] for not keeping quiet. Not to mention all the fud that was spread for an issue that is not even caused by GPG but by bad clients (in fact I am not aware of any client that is vulnerable to this). Shame both to the publishers of this and to the EFF for he…

Also, the second attack seems quite similar to https://eprint.iacr.org/2005/033.pdf .

It's not. The MDC-stripping attack on PGP is very well known --- it's obvious from the structure of the protocol. The paper you're citing uses it to build a direct plaintext recovery attack similar to a padding oracle. Today's paper uses ciphertext malleability to inject active content that exfiltrates the plaintext.

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

#113

Post by tptacek »

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…

Encrypted mail that only works when attackers can't intercept your mail might just as well not be encrypted.

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

#114

Post by tptacek »

Xylakant wrote: post #109
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

Aren’t modern ciphers checksummed and authenticated blockwise? If so, you could just abort the moment you see a broken block. Anything before that block would not be under the attackers control and harmless.

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.

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

#115

Post by CiPHPerCoder »

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…

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

No, they don't. I described a naive RSA+AES hybrid cryptosystem here that includes HMAC authentication without a pre-shared key: https://paragonie.com/blog/2018/04/protecting-rsa-based-prot...

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

#116

Post by cromwellian »

geocar wrote: post #15
cromwellian wrote: post #14

I see how this can be used to exfiltrate an email you’ve sent to others, but th exploit doesn’t seem to show how to exfiltrate private emails between other parties. I mean, it’s an interesting bug, but since the only I can exfiltrate is the contents of plaintext I sent you in the same exploit then it doesn’t seem to leak anything other than any HTML email does. Am I missin something?

Sure. Assume you're a state-actor who wants to read someone's email. You can force their ISP to add code to their SMTP server that adds an efail-pixel jacket, but you can't force them to turn over the customer keys.

Ah ok, I see, it’s kind of a replay attack. Seems like SMIME itself is broken because it doesn’t do whole message integrity.

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

#117

Post by Xylakant »

tptacek wrote: post #114
Xylakant wrote: post #109

Earlier quoted context omitted.

Aren’t modern ciphers checksummed and authenticated blockwise? If so, you could just abort the moment you see a broken block. Anything before that block would not be under the attackers control and harmless.

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

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

#118

Post by colemannugent »

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

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

#119

Post by sp332 »

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

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.

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

#120

Post by tptacek »

mehrdadn wrote: post #17

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.

Post reply on HN