Re: [openpgp] Disabling compression in OpenPGP

[Gregory Maxwell <[e-mail]>]

On Wed, Mar 19, 2014 at 3:58 PM, Jon Callas <[e-mail]> wrote:
> It is! It's a really cool failure mode, and I think you should write it up and submit it to some security conference.

Its old and well known and unsurprising to people who actually work on
cryptographic software.

No amount of presentations at security conferences will actually
protect users, however, unless the default and recommended behavior
changes.

> Please give other cases.

The original post in this thread gave another case, I was adding
another example case where security was compromised in practice.

In the original post PGP is used to encrypt messages containing a
password to access some service, just a password management use— (this
is something that I also happen to do, so I'm doubtful that it's that
fringe an application).  The poster points out that knoweldge of the
size leaks a considerable amount of information about the password.

> In the usual case, Alice sends a free-form message to a set of recipients. There's no leak in this case.

I think its debatable if free form messages are actually the most
common usage of PGP in practice. But thats not here or there, while
working on security the worst cases are usually more important.  In
the usual case no one cares to sniff your email at all and even if
they do you're not saying anything important, not using encryption
saves cpu cycles and avoids compatibility problems. ... but it isn't
the usual cases that we need to protect against.

> The workarounds here are:
> 1. Add a no-compression flag to the receiving key.
> 2. Add "-z 0" to the command line that generates those messages.

These aren't actual workarounds because they do not address the
problem that an otherwise highly conscious user would be unaware that
they need to take these steps.  Would you also respond with "Add
--cipher aes" if I were complaining that ROT13 was not a good default
cipher? :)

>> Care to elaborate on how they rely on it? That seems highly suspect to me.
> tar -c source-tree | gpg key >source-tree.pgp.gz
> This is also what at PGP Corp we called a "PGP Zip" file, which was implemented as a PGP encrypted tarball. It's done all the time in back-end systems, and very likely the second largest use of PGP, where signing files is the most. It's a really useful idiom.

Okay, I think you're using a different definition of rely.  Obviously
if you don't upgrade software nothing changes. Its not unusual that
upgrading software changes behavior. If you upgraded to a version that
didn't compress by default, the end result would be those backups
would be larger.  You'd either not notice and care or you would, and
then after some hunting for the release notes you'd twilddle a knob
and nothing irreparable happens.

> I'm really sorry your ballots got spoiled.

This was years ago (IIRC 2006), I don't care about the event anymore.
I brought it up as a real world example of where this behavior
compromised the security the users reasonably expected.  Not just a
theoretical weakness to counter the claims that the compression harms
nothing, but an actual example of where it happened.

Can you show anything as remotely strong for the assertion that
compression improves security?

On Wed, Mar 19, 2014 at 4:08 PM, ianG <[e-mail]> wrote:
> Clearly, compression leaks info if there is some understanding of the
> structure of the message.  Sure.  But OpenPGP is typically used to ship
> lots of large documents around, and people are accustomed to getting the
> compression bounty for free.
>
> So there is a sense that in order to protect the very few who might fall
> for this case, we'll end up disadvantaging a wider population who might
> actually suffer more.

Well, there are compromises such as padding the post-compression size
to a common interval.

I'm not a super big fan of that because you still may be invisibly
doomed by compression, but I assume (eek) that the cases where the
leaks are really fatal are ones where the messages tend to be quite
small.

> The assumption here is that constant length is somehow more secure than
> inconstancy.

It's generally fairly intuitive to users who are being thoughtful that
the length of the message is a side-channel. In the case of the
Wikimedia ballots the people who set it up thought of that, and
arranged it so that ballots were permutations.

> Then you get the same problem;  *length leaks some info*.  This seems to
> be with or without compression, so is this just a case of choosing ones
> pathology?

The distinction being that the leak happens at a level which is
immediately visible to the thoughtful user vs in a way which is pretty
thoroughly hidden and ...

> There is no fundamental way to overcome the flaw of length in a packet

which can't be completely fixed without unreasonable costs, as you note.

One shouldn't decline to make improvements in some things because
other things cannot be improved.

One point here is that it's non-deterministic too in that you could
test and confirm that your ballots all showed up the same size but the
users system has a different compression preference or library
(deflate is not deterministic, the encoder has freedom) and they're no
longer the same size when the users use them.

> I see this in my work all the time.  Error packets are 10 bytes long,
> success is like 500 bytes.  This is leaking info ... my only solution is
> to make all packets like 1024 bytes, but some of my packets are longer.
>  How far do I go?  Answer:  I've got better things to worry about right
> now.  YMMV.

Padding to reduce the leakage is interesting even if it doesn't
eliminate it entirely because its cheap, and obscures the least
significant bits which often (ahem, assumptions) are the greatest
entropy leak.

At some point it's indeed too costly to fix and not worth it. But I
argue that getting the details as right as possible is why people
should be using standards and popular software and not just encrypting
everything on their own.