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

161–170 of 306 posts

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

#161

Post by tptacek »

xoa wrote: post #160
tptacek wrote: post #144

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

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

#162

Post by rocqua »

r3bl wrote: post #53
rocqua wrote: post #23

Earlier quoted context omitted.

/Donns alufoil hat Google likes HTTPS, it makes the web safer, and keeps middle-boxes from interfering with their stuf. However, Gmail likes access to the plaintext stuff. They no longer use email content for ad-targeting, but they still need this access for spam-filtering and auto labeling. Gmail is essentially e-mail for a lot of people, so what they do matters.

HTTPS means encryption in transit. Email are also encrypted in transit (almost) universally. Encryption in transit has absolutely nothing to do with keeping the data hidden from the service you're visiting.

My point exactly, google helped with the transition to HTTPS, but doesn't want to help the transition to encrypted email.

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

#163

Post by eyeareque »

baby wrote: post #71

Matt Green gave a pretty good summary of this: https://twitter.com/matthew_d_green/status/99598925414360678... Some of these thoughts are echoed by Filippo: > No, in 2018 you don’t get to claim the high ground and blame users and implementations if your crypto API returns the plaintext on a decryption error. from https://twitter.com/FiloSottile/status/996010161427935233 So yeah, most clients seem vulnerable but since…

It’s known that remote image loading is bad. Why is this even enabled? I think they get a pass on this, it’s definitely a bit over blown.

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

#165

Post by dane-pgp »

zaarn wrote: post #37
AnaniasAnanas wrote: post #26

Earlier quoted context omitted.

GPG is not a standard, the standard is OpenPGP. As for the tools, they seem very easy, especially engimail which IS 1-click setup. > add generic messages about encryption in alternate mime content bodies and simply encode the encrypted messages into it's own This is exactly what it is doing. PGP/MIME is a thing.

Enigmail is far from friction free and no 1-click setup. I still have to go through key generation last I checked. And then publish those keys or give them to friends. If PGP/GPG wants adoption they need to eliminate those friction points, a TOFU model with automatic key redistribution should lower friction sufficiently but except TOFU there isn't much development in that direction. >This is exactly what it is doing.…

Your desire for "a TOFU model with automatic key redistribution" is well-founded, and people (including implementers) are trying to do something about this. Check out the Autocrypt project:

https://autocrypt.org/

A similar (and complementary) approach is outlined in RFC-7929:

https://tools.ietf.org/html/rfc7929

which is supported by GPG and a few email providers.

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

#166

Post by yrro »

lmm wrote: post #65
zaarn wrote: post #11

Earlier quoted context omitted.

E-Mail needs better tools and better standards than GPG IMO. For one, GPG tools are difficult to use. Anything beyond a simple 1-click-setup-ready-to-use-including-keyserver-publication will make any wide market adoption difficult. On the other, the GPG standard is a bit ... clunky. Ideally it should be modernized to take advantage of the email format; add generic messages about encryption in alternate mime content b…

Better tools yes, better standards no. There isn't a single production-quality library implementation of the OpenPGP standard; anyone who uses OpenPGP in production ends up with some variant on a crappy 700-line python script wrapping the GPG executable. (There are dozens or hundreds of those out there, every company has their own). I'll never understand what possesses people who aren't up to writing a solid library…

Forgive me but isn't GPGME the high level library that programs probably want to use rather than dealing with gpg's protocol themselves?

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

#167

Post by cyphar »

AnaniasAnanas wrote: post #26
zaarn wrote: post #11

Earlier quoted context omitted.

E-Mail needs better tools and better standards than GPG IMO. For one, GPG tools are difficult to use. Anything beyond a simple 1-click-setup-ready-to-use-including-keyserver-publication will make any wide market adoption difficult. On the other, the GPG standard is a bit ... clunky. Ideally it should be modernized to take advantage of the email format; add generic messages about encryption in alternate mime content b…

GPG is not a standard, the standard is OpenPGP. As for the tools, they seem very easy, especially engimail which IS 1-click setup. > add generic messages about encryption in alternate mime content bodies and simply encode the encrypted messages into it's own This is exactly what it is doing. PGP/MIME is a thing.

> the standard is OpenPGP

The standard is PGP. OpenPGP is an implementation.

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

#168

Post by cvwright »

xoa wrote: post #160
tptacek wrote: post #144

Earlier 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. 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; 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…

At some point, all the recent work that tptacek mentioned on encrypted messengers is going to percolate up into email.

Taking something like megolm [1] and running it over SMTP is such an obvious answer that, eventually, somebody will give it a go. Until then, we get to keep having this argument on the internet every few weeks...

[1] https://git.matrix.org/git/olm/about/docs/megolm.rst

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

#169

Post by rocqua »

eyeareque wrote: post #163
baby wrote: post #71

Matt Green gave a pretty good summary of this: https://twitter.com/matthew_d_green/status/99598925414360678... Some of these thoughts are echoed by Filippo: > No, in 2018 you don’t get to claim the high ground and blame users and implementations if your crypto API returns the plaintext on a decryption error. from https://twitter.com/FiloSottile/status/996010161427935233 So yeah, most clients seem vulnerable but since…

It’s known that remote image loading is bad. Why is this even enabled? I think they get a pass on this, it’s definitely a bit over blown.

The issue is apparently that pgp outputs the plain text to a pipe before checking the MAC in the message. Instead, they provide an error code when the MAC doesn't fail. Apparently a lot of implementations don't check for this error. In general, this leads to message malleability. Malleability is always bad. It just so happens that in this example, they used malleability to sneak in tags.

So the issue here is that PGP outputs plain text even when the message fails the MAC check.

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

#170

Post by rocqua »

tptacek wrote: post #161
xoa wrote: post #160

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

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.
Post reply on HN