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

21–30 of 306 posts

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

#21

Post by AnaniasAnanas »

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.

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

#22

Post by mehrdadn »

rocqua wrote: post #19
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 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?

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

#23

Post by rocqua »

oblio wrote: post #6

While HTTPS is taking over web traffic, encrypted email could be considered a failure, at this point. I wonder what percentage of emails are encrypted using GPG. Based on my experience it's probably less than 0.001%.

/Donns alufoil hat

Google likes HTTPS, it makes the web safer, and keeps middle-boxes from interfering with their stuf.

However, Gmail likes access to the plaintext stuff. They no longer use email content for ad-targeting, but they still need this access for spam-filtering and auto labeling.

Gmail is essentially e-mail for a lot of people, so what they do matters.

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

#24

Post by onlydnaq »

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?

If I want to decrypt a message to you that I have intercepted I can create my own email containing a modification of the intercepted message and send it to you, causing you to send me the plaintext contents.

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

#25

Post by Promarged »

The bug would work only if all of these are true:

  - only-encrypted (not signed) message (signing is good practice),
  - clients that do not do MDC (MDC was introduced in 2000, every non-prototype client uses it)
  - client that rendered HTML mail with broken markup,
  - client that automatically fetches remote resources.
tl;dr this is a very narrow case

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

#26

Post by AnaniasAnanas »

zaarn wrote: post #11
oblio wrote: post #6

While HTTPS is taking over web traffic, encrypted email could be considered a failure, at this point. I wonder what percentage of emails are encrypted using GPG. Based on my experience it's probably less than 0.001%.

E-Mail needs better tools and better standards than GPG IMO. For one, GPG tools are difficult to use. Anything beyond a simple 1-click-setup-ready-to-use-including-keyserver-publication will make any wide market adoption difficult. On the other, the GPG standard is a bit ... clunky. Ideally it should be modernized to take advantage of the email format; add generic messages about encryption in alternate mime content b…

GPG is not a standard, the standard is OpenPGP.

As for the tools, they seem very easy, especially engimail which IS 1-click setup.

> add generic messages about encryption in alternate mime content bodies and simply encode the encrypted messages into it's own

This is exactly what it is doing. PGP/MIME is a thing.

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

#27

Post by jwilk »

Promarged wrote: post #25

The bug would work only if all of these are true: - only-encrypted (not signed) message (signing is good practice), - clients that do not do MDC (MDC was introduced in 2000, every non-prototype client uses it) - client that rendered HTML mail with broken markup, - client that automatically fetches remote resources. tl;dr this is a very narrow case

It doesn't matter if the message was signed or not:

https://efail.de/#will-signatures

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

#28

Post by FrantaH »

"To decrypt the emails, he first manipulates their ciphertext by using appropriate malleability gadgets." - so if you use triple wrapping as per https://www.ietf.org/rfc/rfc2634.txt you are safe. e: To make the claim more precise: you must drop messages which are not triple wrapped and those which are triple wrapped, but inner signer is different from the outer signer.

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

#29

Post by foo101 »

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 in the implementation, not the standard.

Post reply on HN