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

#251

Post by loup-vaillant » Mon, May 14, 2018, 11:04 PM UTC

dfabulich wrote: post #243

jwildeboer wrote: post #237

Earlier quoted context omitted.

“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” I honestly don’t care about the rationale, but this inconsistent behaviour is simply wrong. After 18 years of discussion, end this. Whenever DECRYPTION_FAIL occurs, there MUST be no decrypted content.

That's not really compatible with piped output. The encrypted message can't be authenticated until it has been completely processed, but the whole point of piping is to output bytes as soon as they're available. Perhaps the moral of this story is to disable GPG's pipe feature? But it's a legitimate and significant performance improvement for authentic messages. You "just" have to remember to check the error code and…

This is why I initially hesitated to implement a streaming interface for my crypto library¹ (authenticated encryption and signatures). I eventually did it, but felt compelled to sprinkle the manual with warnings about how streaming interfaces encourage the processing of unauthenticated messages.

Now that we have a vulnerability with a name, I think I can make those warning even scarier. I'll update that manual.

[1]: https://monocypher.org/

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

#252

Post by bscphil » Mon, May 14, 2018, 11:04 PM UTC

tom_mellior wrote: post #99

jcranmer wrote: post #85

Earlier quoted context omitted.

Thunderbird disables remote loading by default. It's vulnerable only if you take measures to override this, which is to say, you either: 1. Use movemail to receive email instead of IMAP or POP (there's an interesting vector to get your remote resources loaded by using movemail. If you read the code, you can probably guess it). 2. Enable remote loading for all senders by default. 3. Try to send an email with a sender…

> Thunderbird disables remote loading by default. From the paper: "For example, in Thunderbird and Postbox we can completely redress the UI with CSS and trick the user into submitting the plaintext with an HTML form if he clicks somewhere into the message." This is bad news. Also, they claim/suggest that the following: is a "bypass for remote content blocking" in Thunderbird, whatever that may mean exactly. EDIT: Moz…

Allowing preconnects when remote resource loading is disabled would be a serious security fail, so I hope that's not what Thunderbird is doing. Suppose I initiated a connection to long-unique-identifier.mysite.com? At minimum this could be used for tracking beacons, possibly even to exfiltrate data.

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

#253

Post by tptacek » Mon, May 14, 2018, 11:13 PM UTC

smsm42 wrote: post #248

tptacek wrote: post #173

Earlier quoted context omitted.

Why would that be a good thing? You'd still be left with a system that leaks immense amounts of metadata, which is often all government adversaries really care about, where the majority of the installed base isn't encrypted and you have to interoperate, and the vast majority of users gets access to messages through a web browser and so is hamstrung on secure delivery of encryption in the first place. Just stop using…

> a system that leaks immense amounts of metadata Doesn't Signal require you to publish your actual phone number, which reveals your RL identity in the network pretty much completely controlled by government?

No.

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

#254

Post by tptacek » Mon, May 14, 2018, 11:23 PM UTC

dfabulich wrote: post #243

jwildeboer wrote: post #237

Earlier quoted context omitted.

“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” I honestly don’t care about the rationale, but this inconsistent behaviour is simply wrong. After 18 years of discussion, end this. Whenever DECRYPTION_FAIL occurs, there MUST be no decrypted content.

That's not really compatible with piped output. The encrypted message can't be authenticated until it has been completely processed, but the whole point of piping is to output bytes as soon as they're available. Perhaps the moral of this story is to disable GPG's pipe feature? But it's a legitimate and significant performance improvement for authentic messages. You "just" have to remember to check the error code and…

That is not the whole point of piping, and the default behavior of GPG should be to buffer, validate the MDC, and release plaintext only after it's been authenticated. Pipes are a standardized Unix interface between processes, not a solemn pledge to deliver bytes as quickly as possible.

If pipes had the connotation you claim they do, it would never be safe to pipe ciphertext, because the whole goal of modern AEAD cryptography is never to release unauthenticated plaintext to callers.

Clients encrypting whole ISO images should expect that decryption will require a non-default flag. Ideally, GPG would do two-pass decryption, first checking the MDC and then decrypting. Either way, the vast, commanding majority of all messages GPG ever processes --- in fact, that the PGP protocol processes --- should be buffered and checked.

If you have a complaint about how unwieldy this process is, your complaint is with the PGP protocol. The researchers, and cryptographers in general, agree with you.

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

#255

Post by tptacek » Mon, May 14, 2018, 11:34 PM UTC

mjw1007 wrote: post #202

tptacek wrote: post #152

This is the worst reaction to a serious and interesting vulnerability I think I've ever seen on HN. The problem being exploited today is that PGP isn't properly authenticated. PGP has an authenticator, but it's simply the SHA-1 of the plaintext appended to the message. Since even that SHA-1 was a later addition to the protocol, mainstream PGP implementations will process messages that lack the hash and decrypt the me…

> But popular mainstream GPG clients don't honor that warning, which doesn't say "Stop, don't process this plaintext I am showing you", but rather "message was not integrity protected". As more information is coming out, it begins to seem that this is not the case: it looks like most GPG clients do detect the warning/error. Looking at the table in the paper, most clients weren't vulnerable when using GPG rather than…

Incidentally: I'm sure there's some version of GPG that doesn't print DECRYPTION_OKAY when the MDC is stripped, but if I encrypt --disable-mdc and then decrypt --status-fd 1, I get DECRYPTION_OKAY and an exit code of 0.

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

#256

Post by tptacek » Mon, May 14, 2018, 11:36 PM UTC

giancarlostoro wrote: post #32

foo101 wrote: post #29

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 i…

It's been mentioned by other comments here[0] that the team / group / individual(s) behind this paper didn't even contact the underlying development teams prior to publishing. The whole thing looks like they want to be able to say "yeah we uncovered xyz vulnerability" which they kind of could of, if they had just explained it's relevant to implementation and didn't attack the wrong projects in the process. There seem…

This is false, and you should be embarrassed to have repeated it publicly.

If you'd even taken the time to look at the Efail.de website, you'd see the (extensive) timeline of contacts the Ruhr team made, including liasing with CERT teams, starting last year.

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

#257

Post by loup-vaillant » Mon, May 14, 2018, 11:36 PM UTC

tptacek wrote: post #233

AnaniasAnanas wrote: post #222

Earlier quoted context omitted.

> not leak the contents of our messages to anyone who can intercept them Already a thing, next? > forward secrecy There is https://tools.ietf.org/html/draft-brown-pgp-pfs-03 but to be honest forward secrecy in general does not make much sense in the context of email or backups.

Forward secrecy doesn't make sense in the context of email? Please, go on.

If you know of a way of ensuring forward secrecy without a response from the recipient, I'm all ears. Considering that NaCl's crypto_box() interface doesn't provide forward secrecy, I feel somewhat safe in believing it's flat out impossible.

Sure, the sender can generate a temporary key pair, and immediately toss out the private half. A passive recipient however cannot do the same. We need a handshake of some sort.

If you want that handshake for email, I don't know how to do that without giving the long term keys to the mail server, which in most cases is operated by a third party that reads your emails for a living. I'd love to have a solution for that, but I don't believe there is any.

Simply put, forward secrecy doesn't make much sense in the context of email.

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

#258

Post by dfabulich » Mon, May 14, 2018, 11:43 PM UTC

tptacek wrote: post #254

dfabulich wrote: post #243

Earlier quoted context omitted.

That's not really compatible with piped output. The encrypted message can't be authenticated until it has been completely processed, but the whole point of piping is to output bytes as soon as they're available. Perhaps the moral of this story is to disable GPG's pipe feature? But it's a legitimate and significant performance improvement for authentic messages. You "just" have to remember to check the error code and…

That is not the whole point of piping, and the default behavior of GPG should be to buffer, validate the MDC, and release plaintext only after it's been authenticated. Pipes are a standardized Unix interface between processes, not a solemn pledge to deliver bytes as quickly as possible. If pipes had the connotation you claim they do, it would never be safe to pipe ciphertext , because the whole goal of modern AEAD cr…

What is the point of piping, in your view? My understanding is that it's a stream of bytes with backpressure, designed specifically to minimize buffering (by pausing output when downstream receivers are full/busy).

> If pipes had the connotation you claim they do, it would never be safe to pipe ciphertext, because the whole goal of modern AEAD cryptography is never to release unauthenticated plaintext to callers.

You say that like it's a reductio ad absurdum, but I think that's essentially right; you can't do backpressure with unauthenticated ciphertext. You have to buffer the entire output to be sure that it's safe for further processing.

Thus, if you want to buffer the entire output, don't use a pipe; ask the tool to generate a file, and then read the file only when the process says that the file is done and correct.

(I'd say that's a lot more wieldy than two-pass decryption.)

Based on your other remarks about PGP, (nuke it from orbit) I'm not sure you have any constructive remarks to make on how to improve GPG, but I guess making it two-pass by default (with a --dangerous-single-pass flag) would be an improvement.

For normal size emails, users probably wouldn't notice the performance cost of the second pass, and clients who care about performance at that level can opt into single-pass decryption and just promise to check the error code.

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

#259

Post by tptacek » Mon, May 14, 2018, 11:43 PM UTC

loup-vaillant wrote: post #257

tptacek wrote: post #233

Earlier quoted context omitted.

Forward secrecy doesn't make sense in the context of email? Please, go on.

If you know of a way of ensuring forward secrecy without a response from the recipient , I'm all ears. Considering that NaCl's crypto_box() interface doesn't provide forward secrecy, I feel somewhat safe in believing it's flat out impossible. Sure, the sender can generate a temporary key pair, and immediately toss out the private half. A passive recipient however cannot do the same. We need a handshake of some sort.…

I don't understand any part of this argument. What wouldn't make sense would be for crypto_box() to provide forward secrecy, since it isn't a messaging protocol, but rather a simple primitive for authenticated public key encryption --- a low-level building block from which you build protocols.

It's obviously not impossible to build basically any peer-to-peer end-to-end protocol using email as a transport. But, if you were right, and it was, that wouldn't mean "forward secrecy doesn't make sense for email"; it would mean "cryptographic security doesn't make sense for email".

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

#260

Post by tptacek » Mon, May 14, 2018, 11:44 PM UTC

dfabulich wrote: post #258

tptacek wrote: post #254

Earlier quoted context omitted.

That is not the whole point of piping, and the default behavior of GPG should be to buffer, validate the MDC, and release plaintext only after it's been authenticated. Pipes are a standardized Unix interface between processes, not a solemn pledge to deliver bytes as quickly as possible. If pipes had the connotation you claim they do, it would never be safe to pipe ciphertext , because the whole goal of modern AEAD cr…

What is the point of piping, in your view? My understanding is that it's a stream of bytes with backpressure, designed specifically to minimize buffering (by pausing output when downstream receivers are full/busy). > If pipes had the connotation you claim they do, it would never be safe to pipe ciphertext, because the whole goal of modern AEAD cryptography is never to release unauthenticated plaintext to callers. You…

Backpressure is a feature of Unix pipes. It isn't their raison d'être.

I don't care how you implement it, but any claim that you can't check the MDC in GPG because it's a piped interface is obviously false. GPG can, like any number of Unix utilities, some casually written and some carefully written, simply buffer the data, process it, and write it.