Huh, PGP encrypted messages aren't authenticated? (No HMAC etc)
[deleted]
EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME
41–50 of 306 posts
Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME
#42Earlier quoted context omitted.
Also relevant https://lists.gnupg.org/pipermail/gnupg-users/2018-May/06032...
This seems to contradict the earlier claim that "the GnuPG team was not contacted by the researchers".
It however confirms that the OpenPGP devs had no knowledge of an embargo, and thus didn't break any embargo. Sebastian Schinzel claimed they had to publish early because the embargo broke.
Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME
#43Earlier quoted context omitted.
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?
In this case (cbc) the IV is the nonce though for some kind of reason people like to mix words and make everyone's life more difficult. As far as I have encountered, almost always the word nonce applies to some randomization and IV is basically the first data into the system, even if it is not random.
Since most embedded platforms have limited entropy and/or no hardware RNG it is more difficult to generate proper distinctive, unpredictable iv's (in the case of CBC). If most of the nonce is random and the rest predictable (like GCM) the same problem applies. The nonce for GCM for instance is at least 8 bytes random in most implementations.
There are enough ways to generate sufficiently randomized iv's. People just don't bother usually. (guess 0 as an iv for instance on many embedded systems).
Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME
#44Huh, PGP encrypted messages aren't authenticated? (No HMAC etc)
Most clients incorporate Authenticated Encryption but since some don't work well with it, it is not a decrypt failure if not present. It should be and solves the problem as per what Koch said [1].
[1] https://lists.gnupg.org/pipermail/gnupg-users/2018-May/06031...
Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME
#45[deleted]
Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME
#46From what I've read, I thought that in modern cryptographic methods you always authenticate and encrypt, in part to avoid attacks like this where an attacker can modify the encrypted message in some way. Does this mean that GnuPG and S/MIME don't authenticate/sign encrypted messages at all? Or that email clients still try to display encrypted messages that are not properly authenticated?
[deleted]
Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME
#47That's an incredibly weak vulnerability. HTML images, seriously? Who the hell autoloads HTML images in email in 2018? If you don't autoload images, you're safe - so for example on Thunderbird, everyone is safe by default. This is not a big deal at all.
Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME
#48This hardly seems like an OpenGPG or S/MIME vulnerability to me and more like an XSS-like exploit of email clients.
The encryption system should be saying "BAD MESSAGE" to the client and instead it is saying "Here's the message and some malware".
Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME
#49Huh, PGP encrypted messages aren't authenticated? (No HMAC etc)
If I have your key, I can send you an encrypted GPG message, without you needing to know who am, or for any kind of message from you back to me. HMACs require a shared secret.
GPG does optionally support signing, which provides for integrity for message contents, but it is optional, so is not a useful mitigation here.
It supports a Modification Detection Code (MDC), which is just a hash of the message. In scenarios where GPG won't decrypt without an MDC being present, it would be a reasonable defence against this attack, because to generate a valid MDC, you would need to know the entire contents of the message, and if you know the entire contents of the message, you wouldn't gain anything from this attack.
Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME
#50As if a brand name, logo and website were not enough, even the white paper title is cringy clickbait: "Efail: Breaking S/MIME and OpenPGP Email Encryption using
Exfiltration Channels".
OpenPGP is not broken. Nothing in your paper has anything to do with OpenPGP. This is simply spreading overblown FUD for your 15 minutes of mainstream media fame.