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

281–290 of 306 posts

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

#281

Post by wodny »

JoachimSchipper wrote: post #201
tptacek wrote: post #113

Earlier quoted context omitted.

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

It's not exactly PGP's security model, but: - if you use SMTP-via-TLS and (IMAP/POP/MAPI)-via-TLS, attackers really can't intercept your mail - unauthenticated encryption still protects your mail spool at rest. Of course, attackers gaining access to your mailbox is still game over, due to password resets etc. via e-mail; but "attackers can't intercept your mail" is a more realistic assumption in 2018 than it was when…

Not necessarily. Mail can be intercepted when transferred between MTAs which seem to be often vulnerable to STARTTLS stripping due to a fallback mechanism. See "Neither Snow Nor Rain Nor MITM... An Empirical Analysis of Email Delivery Security"[1].

[1]: https://conferences.sigcomm.org/imc/2015/papers/p27.pdf

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

#282

Post by tome »

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…

Isn't it possible to adjust any existing authentication scheme to authenticate block-by-block?

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

#283

Post by JdeBP »

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…

You are getting your concepts confused. Pipes are one thing, but the concept at hand is in fact filters, programs that primarily read data from their standard inputs and write other (processed) data to their standard outputs. What pipes involve is a red herring, because filters do not necessitate pipes. Filters have no requirements that they write output whilst there is still input to be read, and several well-known filter programs indeed do not do that.

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

#284

Post by shinigami »

cyphar wrote: post #273
shinigami wrote: post #271

Earlier quoted context omitted.

Yes, but that's an online protocol. The problem here is data at rest...

All of the cipher suites I mentioned can be used with at-rest data (including ChaCha20-Poly1305, and AES-{GCM,EAX,OCB}), which means that there's nothing stopping PGP from adding support for them. But since you asked, the offline backup software restic[1] uses AEAD (though it's a mix of AES-256-CTR and Poly1305 rather than AES-GCM[2] -- but it's still an AEAD construction). I also recently started working on a paper-…

AEAD is not enough. How do you decrypt/verify a 100 GB file with AEAD, without disclosing unauthenticated plaintext in a single pass? You need streaming AEAD like STREAM or CHAIN.

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

#285

Post by twr »

smsm42 wrote: post #275
smsm42 wrote: post #274

Earlier quoted context omitted.

This article explains how to create a second phone number, for usage for Signal. Which confirms my assertion that you need phone number, and makes your statement of "no" completely false. Among options offered: The desk phone at your office. A free Google Voice phone number, if you live in the United States (this is what I do). Any phone number from any online calling service, like Skype. A cheap pre-paid SIM card fo…

As an added bonus, some of these creative solutions also make MITM-ing the whole scheme as trivial as "our corporate phone tree has changed, please use new number 1-555-666-666 to contact me from now on". You have no way to verify it, nobody knows how corporate trees and phone prefixes look like. And of course if the person is fired or reassigned or leaves the job (which never happens!), their account is now under co…

Signal doesn't entrust security to carriers. Messages are sent E2E encrypted to the registered device over the internet. If someone MitMs a device, the safety numbers would not match on either end.

Signal, and the Signal server operators, malicious or not, do not know the phone numbers of people you are communicating with (presuming the secure enclave on the server isn't cracked). Signal does know your phone number, so someone could figure out if you use Signal. If you're worried about that, or personal sharing of your number, you could falsify information to create an anonymous phone number, or you can just use Matrix or Wire.

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

#286

Post by cyphar »

shinigami wrote: post #284
cyphar wrote: post #273

Earlier quoted context omitted.

All of the cipher suites I mentioned can be used with at-rest data (including ChaCha20-Poly1305, and AES-{GCM,EAX,OCB}), which means that there's nothing stopping PGP from adding support for them. But since you asked, the offline backup software restic[1] uses AEAD (though it's a mix of AES-256-CTR and Poly1305 rather than AES-GCM[2] -- but it's still an AEAD construction). I also recently started working on a paper-…

AEAD is not enough. How do you decrypt/verify a 100 GB file with AEAD, without disclosing unauthenticated plaintext in a single pass? You need streaming AEAD like STREAM or CHAIN.

Doesn't OCB allow you to stream and verify in a single-pass (because the MAC is embedded in the 128-bit blocks of the underlying cipher blocks)?

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

#287

Post by aleks_me2 »

I have read the statement on eff https://www.eff.org/deeplinks/2018/05/not-so-pretty-what-you... and can't think about that this is a PR for Signal. I assume that signal will start some e-mail services soon and try now to shade the current mostly safe communication tools in bad light. I hope I'm wrong, the future will it shows.

It would be interesting to know if the https://darkmail.info/ initiate is still active. As far as I understand this solution are the metadata also invisible at the transport level. Can anyone shade a light on this?

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

#288

Post by a3_nm »

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…

Is it so easy for GPG to buffer the cleartext while validating the MDC? As the cleartext may not fit in RAM, this means that GPG could need to write it to a temporary file, right? But then, if decryption is aborted messily (e.g., the machine loses power), then this means that GPG would be leaving a file with part of the cleartext behind, which has obvious security implications.

You could also imagine a two-pass approach where you first verify and then decrypt, but then what about a timing attack where a process would be modifying the encrypted file between the two passes?

It doesn't look so easy to solve this problem -- arguably the right way would be to change the design of the OpenPGP protocol, cf https://www.imperialviolet.org/2014/06/27/streamingencryptio...

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

#289

Post by belorn »

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…

The reaction is the result of when people's expectations from reading about the attack do not match the actual impact. It has been presented as a fundamental issue with PGP with the recommendation to uninstall and stop using anything associated with it.

I use such programs every day, have developed software which directly use GPG, and administrate servers that depend on GPG every day. Not a single use case is affected by EFail. GPG can still be used by Debian maintainers to sign packages and emails, backups can be encrypted, passwords stored in managers, and so on. Even encrypted email, which is the target of the exploit, have minimal or no impact on me since everyone I know who communicates with encrypted emails have HTML turned off and get big massive warning when the signature is missing (or failed).

EFail can be describe in a single sentence: unsigned PGP data will only give warning when MDC is missing, potentially leaking plaintext in mail clients that render HTML. The scope of this looks to be quite small and a far cry from the suggested idea to uninstall GPG and abandon everything it has touched.

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

#290

Post by jkaplowitz »

twr wrote: post #285
smsm42 wrote: post #275

Earlier quoted context omitted.

As an added bonus, some of these creative solutions also make MITM-ing the whole scheme as trivial as "our corporate phone tree has changed, please use new number 1-555-666-666 to contact me from now on". You have no way to verify it, nobody knows how corporate trees and phone prefixes look like. And of course if the person is fired or reassigned or leaves the job (which never happens!), their account is now under co…

Signal doesn't entrust security to carriers. Messages are sent E2E encrypted to the registered device over the internet. If someone MitMs a device, the safety numbers would not match on either end. Signal, and the Signal server operators, malicious or not, do not know the phone numbers of people you are communicating with (presuming the secure enclave on the server isn't cracked). Signal does know your phone number,…

My experience of Signal is that people don't reliably follow up on safety number changes, yet keep using it in a MITM-vulnerable way. Including myself, honestly, because people change or reset phones frequently. Is your experience different?

At least with GPG I can factory reset all of my computers and phones and not have to re-establish trust if I take the right steps to preserve the secret key information.

Even if I don't preserve that correctly, people change computers less often than phones.

On the other hand, I'll admit that my GPG key is newer than my Signal number (which I've owned for 15 years), due to upgrading crypto algorithms.

Post reply on HN