One more reason to stop using html emails people...
EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME
181–190 of 306 posts
Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME
#182Earlier quoted context omitted.
> 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. Yes. But unless I've missed something no one has bothered to even attempt any modernized, improved replacement, so we continue to muddle along. I've certainly heard complaints about existing secure email t…
No, contrary to what you're saying, virtually all the work done in retail cryptography over the last several years has been in secure messaging. Don't send secrets over email; use a cryptographically secure messaging application, like Signal or Wire.
That is not contrary to what I'm saying, that is exactly what I'm saying. Much of the world, both corporate and private, do not want "messaging", they want "email". I use scare quotes for the latter because I want to distinguish between email as in existing technical standards dating all the way back to RFC 561 and email as-in that kind of information transfer service and format, distinct from messaging. Messaging has its place too, but there is clearly a desire for an electronic version of sending a piece of mail. It fits human and cultural psychology. It produces a different kind of consideration and formatting, which has both its merits and demerits. But messaging is not a replacement for email. You can insist that it is but I don't think you will be successful, and you should know better then most that security which isn't used isn't useful security.
>Don't send secrets over email
Back here on Planet Earth sending all sorts of secrets over email and using it for authentication of incredibly important accounts is the regrettable rule, not the exception. Like use of passwords. It is the reality in which we live. I see no sign of it changing either unless there is a direct in-place upgrade available. Which there is not.
>replace email with this thing that requires a phone number and is not like email
No.
>replace email with this thing that didn't even bother to add e2e crypto until 2016, claims to be agpl/gplv3 but then adds a bunch of other random crap on top, etc. Also not email.
No.
Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME
#183Earlier quoted context omitted.
It should split it in chunks and authenticate each one of them. Then the worst attack would be the ability to truncate the file, and it could be at least detected. Unfortunately this is not supported by the PGP spec, or any other well established spec.
What's happened here is that GPG has used the OpenPGP spec as excuse to support extremely insecure default behavior. In reality, GPG can simply buffer and check before writing to stdout, and, in the rare cases where messages are too large to buffer, a flag can be used to override the secure default.
Once the MDC clears, you can just decrypt again, this time writing to stdout.
Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME
#184Earlier quoted context omitted.
It strips the PGP MDC and then uses a malleability attack on CFB or CBC to inject content, but it's not a crypto attack? You have a definition of "crypto attack" that nobody in the field uses.
To be fair, a very large part of this attack is not about PGP at all. That part is about abusing email-client rendering of partly encrypted messages, and abusing S/MIME to get message malleability again exploited via HTML.
Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME
#185Tangent: Is it just me or does CBC (and block ciphers in general) always seem to be a troublemaker? Even if it's not directly at fault, it seems to always make everything more difficult to secure, and I don't recall ever having heard of a single benefit gained by using them. Why do people insist on using block ciphers instead of stream ciphers? What benefits do they have?
It's not block ciphers versus stream ciphers. CFB mode is a stream cipher and is implicated in this attack. CTR, the canonical stream cipher, is even more malleable than CBC. The problem is authenticated versus non-authenticated ciphers. CBC, CTR, and CFB are non-authenticated cipher designs. EAX, GCM, and OCB are authenticated designs.
Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME
#186Earlier quoted context omitted.
No, contrary to what you're saying, virtually all the work done in retail cryptography over the last several years has been in secure messaging. Don't send secrets over email; use a cryptographically secure messaging application, like Signal or Wire.
> No, contrary to what you're saying, virtually all the work done in retail cryptography over the last several years has been in secure messaging. That is not contrary to what I'm saying, that is exactly what I'm saying. Much of the world, both corporate and private, do not want "messaging", they want "email". I use scare quotes for the latter because I want to distinguish between email as in existing technical stand…
Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME
#187Earlier quoted context omitted.
Since the exploit depends on sending manipulated emails, I think that 3. and 4. are pretty easy, since it'll look like the email is from a trusted sender (and encrypted)
The encrypted messages will not be signed, unless the trusted sender is also the attacker or their key is compromised.
Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME
#188Earlier quoted context omitted.
So the reasonable answer for me would be “go forth and use a modern scheme by default.”
The issue there is that if you call something PGP, people expect backwards compatibility, but if you switch to a different mode of encryption that becomes a massive pain.
Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME
#189Earlier quoted context omitted.
It woulds still be great to get some sort of protocol that will work over email. This is still the de-facto way of communication. If we can secure it, it would be a massive win. Much like the wide-spread use of HTTPS over HTTP was a massive win.
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…
Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME
#190Earlier quoted context omitted.
> 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. Yes. But unless I've missed something no one has bothered to even attempt any modernized, improved replacement, so we continue to muddle along. I've certainly heard complaints about existing secure email t…
No, contrary to what you're saying, virtually all the work done in retail cryptography over the last several years has been in secure messaging. Don't send secrets over email; use a cryptographically secure messaging application, like Signal or Wire.