Relevant comment from Werner Koch: https://twitter.com/FiloSottile/status/996011473112576000

Either GPG buffers the data and checks for DECRYPTION_FAILED, or the application depending on GPG does. Of the two options, it makes much more sense for GPG to handle this.

This is shades of the curl maintainer rationalizing CURL_SSL_VERIFYHOST=1 not doing any checking, because CURL_SSL_VERIFYHOST=2 does.

The application is likely better equipped to do something reasonable if temporarily storing lots of data is in order.

Still, GnuPG could do the buffering automatically for small messages and force explicit configuration otherwise. The latter might not be realistically enforcable given the compatibility constraints.

DECRYPTION_FAILED should always result with an empty return. Not with the decrypted content.

It might be prudent to have GnuPG return an error exit code instead of just printing a warning on stderr. Currently, it seems that clients (at least when using the shell interface) are supposed to parse the error stream. And even when they do (which many probably don’t), it’s not necessarily obvious that the presence of warnings indicates to the client that the data should not be used.

Yes. It has one job!

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 )

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.

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

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

AEAD is not enough. How do you decrypt/verify a 100 GB file with AEAD, without disclosing unauthenticated plaintext in a single pass? You need streaming AEAD like STREAM or CHAIN.

Doesn't OCB allow you to stream and verify in a single-pass (because the MAC is embedded in the 128-bit blocks of the underlying cipher blocks)?

I'm not sure I understand. In OCB (or any other AEAD) there is a single MAC for the entire ciphertext. You can't decrypt&verify large data in a single pass.

You are completely right that for some constructions (such as ChaCha20-Poly1305, AES-CCM, and possible AES-GCM) there is only a single MAC for the entire ciphertext.

However that is not true for other constructions. AES-OCB is a single-pass cipher that has a MAC for each block (this is actually the main selling feature of OCB). (AES-EAX also has a MAC for each block too, but is two-pass.)

Also, STREAM/CHAIN are also AEAD, so your generalisation can't be always true.

I don't see it. From https://www.rfc-editor.org/rfc/rfc7253.txt :

Function name: OCB-ENCRYPT Input: K, string of KEYLEN bits // Key N, string of no more than 120 bits // Nonce A, string of any length // Associated data P, string of any length // Plaintext Output: C, string of length bitlen(P) + TAGLEN bits // Ciphertext

Only a single tag, exactly like CCM and GCM. Am I missing something?

It depends on what you call "AEAD", of course. For me it's something that generates a single MAC. STREAM/CHAIN can then be used with an underlying AEAD (GCM, CCM, OCB, SIV) to create a "streaming AEAD" that generates multiple chunks, each one of them with a MAC.

I'll be honest, I was going off the Wikipedia description of the algorithm.

But looking at the RFC you're right that there's only one authentication tag (I also looked at the GPG implementation as well as the proposed OpenPGP RFC for AEAD -- and it looks like they implement chunking on top of OCB/EAX/GCM for this reason). I stand corrected.

If the message is too large to buffer, one might also first just decrypt and stream the plaintext into sha-1.

Once the MDC clears, you can just decrypt again, this time writing to stdout.

This is difficult if the input is a nonseekable stream, but that doesn't excuse producing bad output.

That's why I didn't suggest it, but to be fair, you could tee the stream into an intermediate file for a two-pass scheme.

Aren’t modern ciphers checksummed and authenticated blockwise? If so, you could just abort the moment you see a broken block. Anything before that block would not be under the attackers control and harmless.

Modern AE schemes are designed to make it easy to quickly abort the whole decryption operation as soon as an error is detected. But the PGP protocol is from the 1990s, and uses vanilla CBC or CFB and then tacks the SHA-1 hash of the plaintext to the end of the message in a separate record.

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.

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 decoding it. So any message sent with a modern cipher or just requiring message authentication by default would have substantially mitigated the attack.

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 same time, you need to be careful against downgrade attacks.

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.

It could also buffer the ciphertext, doubling CPU time but meaning that message size is constrained by disk space rather than available RAM.

Yes. Show me the right message or nothing at all.