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

261–270 of 306 posts

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

#261

Post by comex »

tptacek wrote: post #253
smsm42 wrote: post #248

Earlier quoted context omitted.

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

Explain? I Googled it and it seems that Signal still doesn’t support having an account that isn’t tied to a phone number. Some of the results suggest working around the limitation by obtaining a phone number just for Signal from third parties, but that’s not a particularly reasonable alternative.

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

#262

Post by dfabulich »

tptacek wrote: post #260
dfabulich wrote: post #258

Earlier quoted context omitted.

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.

Nobody said "you can't check the MDC." Everybody said "you have to check GPG's error code."

And I think it's clear to everybody (in this thread) that GPG's approach is a dangerous blame-the-user approach to API design, even granting that this dangerous approach offers optimum performance (especially relative to adding an entire second pass).

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

#263

Post by cyphar »

shinigami wrote: post #224
tptacek wrote: post #193

Earlier quoted context omitted.

I'm not super psyched to see 1990s crypto vulnerabilities used as an opportunity to promote hipster schemes that literally nobody uses. Virtually all modern cryptosystems handle this problem already.

AEAD was also a hipster scheme that literally nobody used. That's the whole point. In Twitter you even linked to Adam Langley's post where he suggests something exactly like STREAM/CHAIN! Which modern cryptosystems handle this problem? Tahoe-LAFS is the only one that comes to mind. Not being snarky here, I'm genuinely interested in knowing this.

Modern TLS uses AEAD in the form of ChaCha20-Poly1305 as well as AES-GCM. I believe that the current standards in AEAD for ciphers are GCM-mode, EAX-mode and OCB-mode (CCM-mode is also used but only because it has no patents while OCB does -- CCM is more complicated and doesn't have some nice properties that OCB has).

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

#264

Post by tptacek »

dfabulich wrote: post #262
tptacek wrote: post #260

Earlier quoted context omitted.

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.

Nobody said "you can't check the MDC." Everybody said "you have to check GPG's error code." And I think it's clear to everybody (in this thread) that GPG's approach is a dangerous blame-the-user approach to API design, even granting that this dangerous approach offers optimum performance (especially relative to adding an entire second pass).

There's no difference. You're talking about the program, I'm talking about the mechanism. Either way:

* GPG should never release unauthenticated plaintext to callers. The exit code is a red herring.

* Nothing about "pipes" prevents them from squelching unauthenticated plaintext.

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

#265

Post by cyphar »

tptacek wrote: post #255
mjw1007 wrote: post #202

Earlier quoted context omitted.

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

I just tried it on my machine (I'm also using gpg 2.2.7) and I got DECRYPTION_FAILED when I do the following:

    % gpg --version
    gpg (GnuPG) 2.2.7
    libgcrypt 1.8.2
    Copyright (C) 2018 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later 
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.

    Home: /home/cyphar/.gnupg
    Supported algorithms:
    Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
    Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
            CAMELLIA128, CAMELLIA192, CAMELLIA256
    Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
    Compression: Uncompressed, ZIP, ZLIB, BZIP2
    % gpg --encrypt --disable-mdc input --output output
    % gpg --decrypt --status-fd 1 --output should_not_exist output | grep DECRYPTION_FAILED
    [GNUPG:] DECRYPTION_FAILED
    % echo $?
    2
    % diff -s input should_not_exist
    Files input and should_not_exist are identical
However (as you can see above), it looks like GPG outputs to the file when it shouldn't (and Werner said that it doesn't so there's definitely a bug here).

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

#266

Post by cyphar »

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.

I don't see why we shouldn't hold clients accountable for not checking error codes from a cryptographic tool. Would you have the same opinion if a client didn't check the error code of 'gpg --verify' -- and thus accepted all signed messages as being valid? I think it's fair to say that there is more than one issue at play here.

FWIW, I completely agree that AEAD should have been added to PGP a long time ago and it's asinine that it hasn't been done yet. Not to mention that it's vulnerable to surreptitious forwarding, and the packet format is insanely complicated and has lots of edge-cases that mean that everyone has to emulate GPG in order to work properly. These things concerned me so much that I decided to use ChaCha20-Poly1305 instead of PGP for a recent project. (I was skeptical of this vulnerability when I first read it, but after sleeping on it and reading comments like yours I decided I was mistaken -- especially since .)

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

#267

Post by loup-vaillant »

tptacek wrote: post #259
loup-vaillant wrote: post #257

Earlier quoted context omitted.

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

Thomas, you're frightening me. I'm talking about relatively basic stuff here. I almost hope I'm wrong.

The only way one could ensure forward secrecy for everyone (sender and recipient), is with a handshake (typically a hail-challenge-response). This handshake can only happen when the recipient is online.

If the recipient is not online, as is expected of asynchronous communication applications such as email, an intermediate server has to hold the message for him. At this point, you either give up on the handshake, or hand over the secret key to the server.

Good luck setting up a trustworthy server. Even if I hosted my stuff at home, I might not be too keen on leaving it on where it could be examined by forensics while I am away. It's not bad, but it's not perfect either. And forget about third party servers, they are untrusted by default. I'd rather give up forward secrecy instead, and keep my private key on an encrypted file on my personal laptop.

So we can't have that hand shake. The protocol has to look like: (i) Alice and Bob know of each other's long term public keys. (ii) Alice encrypts then send a message to Bob. (iii) Bob receives then decrypt that message.

If I knew of a protocol that followed those constraints and still preserves forward secrecy, you could be damn sure I'd put it in Monocypher—one less thing the user could screw up. (Actually, I'd love to be proven wrong there, it would improve my crypto library right away.)

> It's obviously not impossible to build basically any peer-to-peer end-to-end protocol using email as a transport.

You'd still have to give the long term keys to a machine that is online when the message is sent. For asynchronous protocol, this means always online, and we're back to square one.

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

Are you implying that forward secrecy is required for "security"?

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

#268

Post by tptacek »

loup-vaillant wrote: post #267
tptacek wrote: post #259

Earlier quoted context omitted.

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

Thomas, you're frightening me. I'm talking about relatively basic stuff here. I almost hope I'm wrong. The only way one could ensure forward secrecy for everyone (sender and recipient), is with a handshake (typically a hail-challenge-response). This handshake can only happen when the recipient is online. If the recipient is not online, as is expected of asynchronous communication applications such as email, an interm…

All of the first part of your message constitutes much of the rationale behind Signal Protocol, which is asynchronous, does not assume participants are online at the same time, and does not involve you handing secret keys to a server. But, of course, Signal isn't the only way to accomplish forward secrecy.

Am I "implying" that forward secrecy is required for message security? No, I'm saying it directly.

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

#269

Post by jolmg »

EthanHeilman wrote: post #221
jolmg wrote: post #207

Were the development teams of Apple Mail, iOS Mail and Mozilla Thunderbird contacted about this and given time to fix their issues before publication? The page makes no mention of this. It makes it look that this wasn't disclosed responsibly.

>It makes it look that this wasn't disclosed responsibly. Not sure how anyone could say if the disclosure was or was not responsible based on who got advanced warning. Full-disclosure, i.e. all details without any prior warning, can be responsible disclosure. Coordinated disclosure, i.e. providing advanced warning, can be less responsible than full disclosure. It depends on the circumstances and surrounding context.

That might be true in general, but for this particular case, it would seem like it'd be irresponsible to disclose without giving advanced warning to the email client developers. We're talking about giving the chance for journalists, political activists, etc. to be protected from this bug via a typical, routine software update without having to know about the bug before their potential attackers. If the vulnerability is still on, it's now a race on who'll learn the news first, the potential attackers to exploit it or the potential victims to avoid it.

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

#270

Post by tptacek »

comex wrote: post #261
tptacek wrote: post #253

Earlier quoted context omitted.

No.

Explain? I Googled it and it seems that Signal still doesn’t support having an account that isn’t tied to a phone number. Some of the results suggest working around the limitation by obtaining a phone number just for Signal from third parties, but that’s not a particularly reasonable alternative.

https://theintercept.com/2017/09/28/signal-tutorial-second-p...
Post reply on HN