Re: [openpgp] Deprecating compression support

James Howard <james(_dot_)howard(_at_)jhu(_dot_)edu> writes:

> Hello, long-time lurker, first time caller.  As I read this, this
> morning, I fail to see the advantages.  For instance, let’s look at a
> couple of these issues:
>
> > Compression makes it impossible to reason about the size of a
> > decrypted message,
> It’s hard not to look at this and say, good!
What I meant here is that the receiver (i.e. not an adversary) cannot
know in advance how big a decrypted message is by looking at the
encrypted message.  This means that the only safe interface for an
OpenPGP library is a streaming one, and this is perceived as difficult
to use, and/or to increase the complexity of implementations.

> The idea of encryption is the hide information and burying information
> about the length of the message can only be an improvement.
However, compress-then-encrypt leaks the entropy of the plaintext, see
e.g. CRIME, BREACH.

> >   - Compression interacts badly with encryption, see e.g. CRIME,
> >     BREACH, and hiding of EFAIL-style CFB gadgets [0].
> I am not sure how valid this is.  For instance, in the paper cited, we
> see the following comments:
>
> > [F]or OpenPGP, we needed to develop more complex exploit techniques
> > upon malleability gadgets because the data is typically compressed
> > before encryption OpenPGP’s plaintext compression significantly
> > complicates our attack.  The difficulty here is to guess a certain
> > amount of compressed plaintext bytes in order to fully utilize the
> > CFB gadget technique. Not knowing enough compressed plaintext bytes
> > is hardly a countermeasure, but makes practical exploitation a lot
> > harder.
You conveniently left out the very next paragraph, which I will cite
here:

> We show how the compression structure can be exploited to create
> exfiltration channels. Interestingly, with the compression in place,
> we can create exfiltration chan- nels even more precisely and remove
> the random data blocks from the resulting plaintext.

> Then there’s this:
>
> >   - The downstream application is in a better position to decide whether
> >     and how to compress data that is then encrypted using OpenPGP.
> Now, I will admit to misinterpreting this (I think) and assumed you
> meant compressing after application of PGP.  That’s, of course, silly,
I meant compress-then-encrypt, of course.

Justus

PS: Your MUA is terrible, it doesn't preserve quotations.

signature.asc
Description: PGP signature

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp