Re: [openpgp] Disabling compression in OpenPGP

[Gregory Maxwell <[e-mail]>]

On Wed, Mar 19, 2014 at 2:41 PM, Peter Todd <[e-mail]> wrote:
> After realizing that I needed to account for the size of the "Version:"
> string I got the exact same size as your secret for ballot.1, so I'm
> guessing that was your vote.
>
> Am I right?

Indeed, you are.
https://people.xiph.org/~greg/openpgp_testpubkey.secret.asc  password:
qwertyqwerty

On Wed, Mar 19, 2014 at 2:37 PM, Jon Callas <[e-mail]> wrote:
> But it proves nothing here. It's a really, really interesting exception case. We're talking about a default. We're also talking about the protocol definition, and not implementation software.

It's a very highly surprising failure mode which leaks information
about the plaintext by encoding it into the size, one which baffels
otherwise expert users of the sort who would post to the openpgp list
to exclaim "What's being leaked by compression? Really, I don't get
it."

Even thoughtful users who take care to make their messages constant
length will have the implicit compression sneak up and bite them.  Of
course, you could compress and pad up to the original size…

Voting isn't the only case where compression leaks data about the
plain-text, it's just one where I know that it cause and actual
compromise, with actual expert users, in actual practice.

There are a great many people who use gpg to encrypt a small number of
control messages (e.g. for updating route registries and such) where
compression can leak information about the content.

> Compression is on by default because it improves security. It meets that goal. It is, however, a default. Defaults can be changed.

It does not improve security in any practical sense. The presence of
compression harms security severely and in a very practical way in at
least some applications. No cipher should be used where the entropy of
the input is believed to be security relevant, and if one were used,
the compression in gpg still leaves non-trivial known plaintext in
cases where the input begins with known plaintext (in addition to
additional compression headers giving more known plaintext even when
the message is otherwise completely unknown).

(It's possible to design compression systems where the output is
indistinguishable, e.g. arithmetic coders bijective termination, but
none of the supported compressors are designed this way... they will
allow you to detect an incorrect symmetric key with overwhelming
probability with just a dozen bytes of decrypted output or less)

> Moreover, there's a way to work around the issue in the existing standard. Make the vote-submission key not support compression. Poof, it works.

Yea, sure, don't aim the gun at your foot and your foot will not be
shot.  It's true, but it's not always useful.  What do you care about
a specification and software? real engineers encrypt their messages by
hand with pen and paper.

Part of the purpose of the specification and software is that doing
everything 'manually' is too costly and difficult, the specification
hopefully embodies the collected wisdom of careful consideration by
the best available experts.

> However, there are still many people who consider default compression a feature and *rely* on it for their system.

Care to elaborate on how they rely on it? That seems highly suspect to me.

Compression is a useful feature, it's nice that often the base64
encoded encrypted versions are not a ton longer than ascii text... but
if we're going through the trouble of encrypting something then the
encryption really ought to not invisibly leak data about the
plaintext. When something is a general tool used for many applications
then we ought to be assuming a sum-of-all-attacks and not just a very
narrow threat model.

Obviously a size side channel still exists, and might be worth
reducing (e.g. by quantizing message size to a multiple of 512 bytes)
but at least that side channel is highly visible to technical users.