Re: [openpgp] Deprecating compression support

[Gregory Maxwell <[e-mail]>]

On Wed, Mar 20, 2019 at 8:57 PM Jon Callas
<joncallas=[e-mail]> wrote:
> There are a number of attacks on interactive encryption protocols that use differences in different compressed plaintext to learn something about the internal structure of the plaintext. This is obviously bad.
> However, *static* encryption, like OpenPGP doesn’t have this problem.
> Here’s a challenge I give.
> Create two plaintexts, P and P’ where P’ = compress(P). Pick any compression function and any plaintext. Now, encrypt them both, so we have E_1 = encrypt(P) and E_2 = encrypt(P’). Show that there is an advantage to an attacker for recovering P’ from E_2 over recovering P from E_1.
> I assert that if you can, then your cipher is flawed and you need to replace it. There is nothing magical about compressed plaintext that makes it easier to recover.

We've been here before:

https://mailarchive.ietf.org/arch/msg/openpgp/rG-X9rp2jlbyACoosnbxRXjCeys

I buy the combining encryption with compression being useful
argument... but at the same time, openpgp compression is increasingly
far from the state-of-the-widespread-art (e.g. xz) and there probably
isn't much interest in updating it to chase the state of the art
compression (and for short human texts, I think recent machine
learning progress look like they're resulting in significantly higher
amounts of compression, -- just no one has productionized that work
yet).