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

291–300 of 306 posts

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

#291

Post by tptacek »

a3_nm wrote: post #288
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…

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

Again, the cleartext virtually always fits trivially in RAM, and when it doesn't, it can error out and require a flag to process. Yes, this is easy to fix.

OpenPGP needs to change as well, but that doesn't make insecure behavior acceptable in the interim, no matter what Werner Koch thinks.

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

#292

Post by mirimir »

ms7821b wrote: post #277
mirimir wrote: post #244

Earlier quoted context omitted.

OK, so Thunderbird plus Enigmail is probably most popular in Linux. And according to Robert J. Hansen:[0] > By default, GnuPG will scream bloody murder if a message lacks an MDC or if the MDC is invalid. At that point it's up to your email client to pay attention to the warning and do the right thing. Enigmail 2.0 and later are fine, but I can't speak for other systems. So if you use Enigmail, do make sure that you'r…

> So basically, 1) the attacker embeds a link to the encrypted message, 2) the email client fetches and decrypts it, and then 3) sends plaintext back to the attacker. What? The attacker embeds secure content inside a link, not a link to the content. It could come from files stored in a public place or emails.

Thanks.

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

#293

Post by xorcist »

tptacek wrote: post #232
xorcist wrote: post #231

Earlier quoted context omitted.

Nobody is arguing against that, so there's really no one to convince. What's being argued against are statements like "gpg doesn't fail on unauthenticated messages", and "stop using gpg with email" where the former just isn't true and the latter isn't very helpful seeing how the vast majority of gpg usage is things like git workflows which are completely unaffected by this.

Everybody who argues that clients should be more careful checking warning messages and error codes and therefore this isn't a GPG problem is in fact arguing that.

You are being very confrontative for no apparent reason. Arguing that mail clients should not hide decryption errors from users is not "in fact" arguing that gpg should keep leaving plaintext fragments around on errors. Far from it.

But it does not matter how perfect encryption tool you can design if your mail client displays a signature as valid when it is in fact not valid.

If you have constructive opinions on how gpg implements AEAD constructs then why not take them to the mailing list? There are plenty of know-it-all personalities in the open source community, but Werner is not one of them.

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

#294

Post by smsm42 »

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

It entrusts the identity to carriers. What use of having perfect peer-to-peer security if you can't be sure who you are talking to? So you will send the data to Eve in a perfectly secure way, while thinking you're talking to Bob - and that's better than Eve breaking the encryption? I say it's much less work for Eve - instead of employing vast resources to exploit a tiny vulnerability in encryption, she would just need to take over a phone number. And if she works for the government, it's not even a hard thing to do.

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

#295

Post by tptacek »

xorcist wrote: post #293
tptacek wrote: post #232

Earlier quoted context omitted.

Everybody who argues that clients should be more careful checking warning messages and error codes and therefore this isn't a GPG problem is in fact arguing that.

You are being very confrontative for no apparent reason. Arguing that mail clients should not hide decryption errors from users is not "in fact" arguing that gpg should keep leaving plaintext fragments around on errors. Far from it. But it does not matter how perfect encryption tool you can design if your mail client displays a signature as valid when it is in fact not valid. If you have constructive opinions on how…

Speaking of that:

https://www.benthamsgaze.org/2018/05/15/tampering-with-openp...

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

#296

Post by twr »

jkaplowitz wrote: post #290
twr wrote: post #285

Earlier quoted context omitted.

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…

It isn't. I rarely send sensitive messages, however, so I feel that some surveillance potential is acceptable, to save time and effort. The few times where I did, I first verified both ends.

I perform the safety number verifications in exchange for forward and backward secrecy. GPG isn't enough to establish a truly confidential communication channel, I think. (Unless you erase keys after every sent message, maybe.)

I'm not happy with Signal's dependence on a phone. Ideally I'd like to use a pocket-sized SBC for secure messaging. Come to think of it, that sounds rather like a phone. Just, uh, without the cellular hardware, and with a user-installed OS.

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

#297

Post by twr »

smsm42 wrote: post #294
twr wrote: post #285

Earlier quoted context omitted.

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

It entrusts the identity to carriers. What use of having perfect peer-to-peer security if you can't be sure who you are talking to? So you will send the data to Eve in a perfectly secure way, while thinking you're talking to Bob - and that's better than Eve breaking the encryption? I say it's much less work for Eve - instead of employing vast resources to exploit a tiny vulnerability in encryption, she would just nee…

Again, you can be sure, by comparing the safety numbers. It's the same as comparing SSH or GPG key fingerprints. If someone else masquerades as Bob, the numbers won't match. See section III-D3, key fingerprint verification: https://www.ieee-security.org/TC/SP2015/papers-archived/6949...

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

#298

Post by John_KZ »

tptacek wrote: post #144
LinuxBender wrote: post #135

Earlier quoted context omitted.

Is PGP broken? Or the plugins that make PGP easier to use email, that are rendering HTML, or those perhaps what is really broken?

Pretty much the whole cryptography field has been saying PGP is broken for something close to a decade now; the attack published today is an applied refinement of theoretical tools we've had for a very long time. The MAC of a PGP message is the SHA-1 of its plaintext appended to the message. There are coherent ways to downplay today's announcement, but "PGP isn't broken" isn't one of them. The best you can do is "PGP…

>Pretty much the whole cryptography field has been saying PGP is broken for something close to a decade now;

No they don't. Also PGP works just fine. It could use some improvements, but it's doing well.

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

#299

Post by John_KZ »

slrz wrote: post #238
Dylan16807 wrote: post #64

Earlier quoted context omitted.

The use of CBC without proper authentication sounds like a flaw in the standard to me. Especially the line in the FAQ about being able to create a fresh valid signature for an altered ciphertext is not good.

The "create a fresh valid signature" part talks about creating a new signature with the attacker's identity. Sure, technically it's a valid signature but it won't fool anyone regarding the message's authenticity. This is trivially possible for all schemes where you can detach the signature from the message.

>talks about creating a new signature with the attacker's identity

Wait, if the signature isn't created with the same key as the message encryption, how does this even work? Shouldn't the client fail to either decrypt the message or validate the signature?

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

#300

Post by shinigami »

cyphar wrote: post #286
shinigami wrote: post #284

Earlier quoted context omitted.

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

I'm not sure I understand. In OCB (or any other AEAD) there is a single MAC for the entire ciphertext. You can't decrypt&verify large data in a single pass.
Post reply on HN