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

271–280 of 306 posts

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

#271

Post by shinigami »

cyphar wrote: post #263
shinigami wrote: post #224

Earlier quoted context omitted.

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

Yes, but that's an online protocol. The problem here is data at rest...

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

#272

Post by tedunangst »

dfabulich wrote: post #258
tptacek wrote: post #254

Earlier quoted context omitted.

That is not the whole point of piping, and the default behavior of GPG should be to buffer, validate the MDC, and release plaintext only after it's been authenticated. Pipes are a standardized Unix interface between processes, not a solemn pledge to deliver bytes as quickly as possible. If pipes had the connotation you claim they do, it would never be safe to pipe ciphertext , because the whole goal of modern AEAD cr…

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…

You know sort works with pipes, right? It doesn't squirt out mostly sorted output whenever it feels like it.

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

#273

Post by cyphar »

shinigami wrote: post #271
cyphar wrote: post #263

Earlier quoted context omitted.

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

Yes, but that's an online protocol. The problem here is data at rest...

All of the cipher suites I mentioned can be used with at-rest data (including ChaCha20-Poly1305, and AES-{GCM,EAX,OCB}), which means that there's nothing stopping PGP from adding support for them.

But since you asked, the offline backup software restic[1] uses AEAD (though it's a mix of AES-256-CTR and Poly1305 rather than AES-GCM[2] -- but it's still an AEAD construction). I also recently started working on a paper-backup project, and used ChaCha20-Poly1305 over PGP because of the lack of AEAD (and also because it is vulnerable to surreptitious forwarding -- something that AEAD also solves[3]).

There are distinctions between online and offline protocols (mainly related to PFS), but whether or not AEAD-capable cipher suites can be used is not one of them.

[1]: https://restic.net/ [2]: https://blog.filippo.io/restic-cryptography/ [3]: https://www.usenix.org/legacy/publications/library/proceedin...

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

#274

Post by smsm42 »

tptacek wrote: post #270
comex wrote: post #261

Earlier quoted context omitted.

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

This article explains how to create a second phone number, for usage for Signal. Which confirms my assertion that you need phone number, and makes your statement of "no" completely false. Among options offered:

The desk phone at your office.

A free Google Voice phone number, if you live in the United States (this is what I do).

Any phone number from any online calling service, like Skype.

A cheap pre-paid SIM card for a few dollars a month (and temporarily put it on your phone to register your second Signal number).

Twilio, a cloud service that allows developers to write software that makes and receives phone calls and SMS messages.

Obviously, each of those still requires registration within government-controlled phone network, and additionally also may require you to entrust your security to a third party - such as your employer, Google, Microsoft or Twilio. So in fact, you refutation of my assertion "you need to publish a phone number" is "you can have two phone numbers". This is not serious.

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

#275

Post by smsm42 »

smsm42 wrote: post #274
tptacek wrote: post #270

Earlier quoted context omitted.

https://theintercept.com/2017/09/28/signal-tutorial-second-p...

This article explains how to create a second phone number, for usage for Signal. Which confirms my assertion that you need phone number, and makes your statement of "no" completely false. Among options offered: The desk phone at your office. A free Google Voice phone number, if you live in the United States (this is what I do). Any phone number from any online calling service, like Skype. A cheap pre-paid SIM card fo…

As an added bonus, some of these creative solutions also make MITM-ing the whole scheme as trivial as "our corporate phone tree has changed, please use new number 1-555-666-666 to contact me from now on". You have no way to verify it, nobody knows how corporate trees and phone prefixes look like. And of course if the person is fired or reassigned or leaves the job (which never happens!), their account is now under control of some unknown third person.

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

#276

Post by Xylakant »

rocqua wrote: post #242
Xylakant wrote: post #188

Earlier quoted context omitted.

Good old SSH managed to update ciphers. This is certainly easier if Server and client can negotiate, but it’s not impossible for GPG. You could start by adding better modes as an option, later make them default and ask for confirmation when decrypting an old message format. If I read the vulnerability description correctly, it allows stripping the message authentication signature and then trick the client into decodi…

It is possible, but note that SSH is interactive and always had multiple ciphers. On PGP, as far as I can tell, there is no field for the cipher used. So you somehow need to introduce that field somewhere, but be able to deal with files that do not have that field. Possible but very tedious. The non-interactivity seems like it makes it harder to 'negotiate' a version. As there is no way to get clarification. At the s…

Sure, as I mentioned, it’s easier if you can negotiate ciphers. But on the upside, there’s no downgrade attack. If the sender uses a modern cipher, the receiver either supports it or can’t decode the message. Still, that’s not a hard reason to not introduce protocol changes like new ciphers and a new field. Funny that you mention that since currently GPG on my Ubuntu spits out warnings about some feature it does not understand in files encrypted with a newer GPG on my fedora. This actually trips up some of my tooling.

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

#277

Post by ms7821b »

mirimir wrote: post #244
tc wrote: post #138

Let's summarize the situation: Abstract: S/MIME and MUAs are broken. OpenPGP (with MDC) is not, but clients MUST check for GPG error codes. Use Mutt carefully or copy/paste into GPG for now. - Some mail clients concatenate all parts of a multipart message together, even joining partial HTML elements, allowing the decrypted plaintext of an OpenPGP or S/MIME encrypted part to be exfiltrated via an image tag. Mail clien…

OK, so Thunderbird plus Enigmail is probably most popular in Linux. And according to Robert J. Hansen:[0] > By default, GnuPG will scream bloody murder if a message lacks an MDC or if the MDC is invalid. At that point it's up to your email client to pay attention to the warning and do the right thing. Enigmail 2.0 and later are fine, but I can't speak for other systems. So if you use Enigmail, do make sure that you'r…

> So basically, 1) the attacker embeds a link to the encrypted message, 2) the email client fetches and decrypts it, and then 3) sends plaintext back to the attacker.

What? The attacker embeds secure content inside a link, not a link to the content. It could come from files stored in a public place or emails.

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

#278

Post by loup-vaillant »

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

Earlier quoted context omitted.

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.

> All of the first part of your message constitutes much of the rationale behind Signal Protocol

OK, I'll look it up, thanks. Though I suspect I already have (the 3-DH the Wikipedia mentions looks familiar, I suspect it is X3DH). Better than nothing, but not quite perfect.

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

#279

Post by lmm »

yrro wrote: post #166
lmm wrote: post #65

Earlier quoted context omitted.

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?

GPGME is a library that automates the exec-ing and pipeing, with all the issues that come with that (e.g. poor error reporting).

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

#280

Post by marbu »

tptacek wrote: post #144
LinuxBender wrote: post #135

Earlier quoted context omitted.

Is PGP broken? Or the plugins that make PGP easier to use email, that are rendering HTML, or those perhaps what is really broken?

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

Do you mean that gpg is broken for non email use cases as well? Eg. encrypting tarball with backups using gpg and then storing it on some cloud service?

Post reply on HN