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

191–200 of 306 posts

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

#191

Post by shinigami »

tptacek wrote: post #158
shinigami wrote: post #141

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

I agree they should have done that as a stopgap measure, but we should push for security in all cases (e.g. streaming AEAD with STREAM or CHAIN https://github.com/miscreant/miscreant/wiki/STREAM )

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

#192

Post by xoa »

Natanael_L wrote: post #172
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…

It does exist, but has approximately zero users https://saltpack.org/ No PFS, though

FWIW thank you for that, even without PFS and no adoption it's at least interesting to see a more recent effort to work within the flawed existing email system but do a bit better then PGP. Like OpenPGP or S/MIME themselves I guess, simply made with something beyond 90s era crypto experience. Although even for something at that stage I'm surprised they don't have anything I can see about what the identities they use are like in the FAQ at least. That's a significant practical difference in PGP and S/MIME for example.

Now that I think about it there is also a modest effort to simply enhance the UI of the whole deal through transparent embedding vs as an attachment. I think modest efforts of that nature that are evolutionary vs revolutionary around existing installed base will like it or not continue to serve an important practical role.

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

#193

Post by tptacek »

shinigami wrote: post #191
tptacek wrote: post #158

Earlier quoted context omitted.

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.

I agree they should have done that as a stopgap measure, but we should push for security in all cases (e.g. streaming AEAD with STREAM or CHAIN https://github.com/miscreant/miscreant/wiki/STREAM )

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.

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

#194

Post by tptacek »

baby wrote: post #186
xoa wrote: post #182

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

The problem with emails is that you have to deal with a thousand different clients implementing things differently. There is no win there.

I think you misunderstood his argument. It was, "no".

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

#195

Post by tptacek »

acct1771 wrote: post #190
tptacek wrote: post #161

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

Not ready to recommend Riot/Matrix?

I do not recommend it, but it's very probably better than PGP email.

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

#196

Post by AgentME »

floatboth wrote: post #147
A1kmm wrote: post #49

Earlier quoted context omitted.

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

> optional, so is not a useful mitigation here Why in the heck does anyone ever send encrypted-only, non-signed messages?!?!

Other than anonymity, non-repudiation is a possibility. I may not want the recipient of my messages to be able to undeniably prove what I said to them. This case is important if I'm saying unflattering things about a mutual friend, or my messages could be read as admitting a crime, etc.

(Though note that the vulnerability here still applies to signed messages too: https://efail.de/#will-signatures)

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

#197

Post by e12e »

tptacek wrote: post #173
rocqua wrote: post #170

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

Sure, email leaks meta-data.

But at its core, the promise of pgp/gpg is the promise of encrypted and authenticated file transfer.

The file might come from ftp, samba/cifs, Dropbox/Google drive/etc, from tape or HD backup - or come attached to an email.

It may come from yourself, or from a friend.

But the promise is that between the encryption and signing - and the verification and decryption - the file remain the same. The zip file is as (Un)safe to extract, the font as (Un)safe to render - the installer or the executable as (Un)safe.

If you have (authenticated) file encryption, you have encrypted email.

If you want to use authenticated file encryption as a secure messaging platform, you should probably invest in a more sane format for your plaintext file than email. And a better wrapping transport than email.

The fundamental problems with email+pgp as a secure messaging platform isn't pgp alone - but the intersection of email-the-format, email-the-protocol mixed with the mail user agents and their 80s trusting file handling (ok, that's unfair to the 80s, we're still too trusting when it comes to files in general and transclusion in particular).

In short, I don't think we should give up all of pgp as such (open, secure, authenticated file encryption and Web of trust).

But it's probably true that newer protocols are better for "real-time" messaging, and perhaps usenet is better for hold-and-forward.

[ed: I'd love to hear some current informed discussion about: https://saltpack.org/ mentioned in this discussion here. From the previous hn discussion it seems reasonable; a sane format (message pack), authenticated encryption primitives - but I worry a bit about public key handling - is there Web of trust/certificate support - and if so, is it sane? I'm not saying pgp/gpg wot is sane. But neither is ssh (certs) in practice. I'd much prefer wot - were for some applications I could choose arbitrary key/certs as authorative CAs and give out short-lived "certs" (signed public keys with valid from-to).]

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

#198

Post by AnaniasAnanas »

tptacek wrote: post #152

This is the worst reaction to a serious and interesting vulnerability I think I've ever seen on HN. The problem being exploited today is that PGP isn't properly authenticated. PGP has an authenticator, but it's simply the SHA-1 of the plaintext appended to the message. Since even that SHA-1 was a later addition to the protocol, mainstream PGP implementations will process messages that lack the hash and decrypt the me…

> GPG will print a warning

GPG will fail with an error in modern versions.

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

#199

Post by pera »

dmix wrote: post #136
sambe wrote: post #78

Earlier quoted context omitted.

I'm reading this message with little context but it doesn't strike me as having reasons not to be worried. The two suggestions are: a) not to use HTML emails, which seems unlikely in practice; b) to use an obscure-sounding mode which has been implemented in such a way as to depend on the MUA doing multiple things correctly after the GPG code runs. What am I missing here? Is the latter mode on by default and MUA are w…

> a) not to use HTML emails, which seems unlikely in practice I've always used plaintext when using PGP, same with others who have used it with me... I thought it was standard practice. I don't see the point in using HTML for one-on-one encrypted conversations. HTML is for newsletters and similar content. Although I assume this means "don't use HTML at all in your client, not just for encrypted email".

Same here, just good ol' plain text and inlined pgp :)

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

#200

Post by noguespi »

tptacek wrote: post #113
noguespi wrote: post #58

A lot of buzz for a not so critical vulnerability. Well it is critical but very hard to exploit because : 1. Hacker need to intercept the encrypted email. 2. HTML tags/remote content are blocked by default on most email client. Still an important vulnerability, but not enough (for me) to disable enigmail, I know I'm safe with blocked remote content. By the way I hate this kind of "buzz" disclosure. Just disclose full…

Encrypted mail that only works when attackers can't intercept your mail might just as well not be encrypted.

You won't be able to decrypt email just by intercepting them
Post reply on HN