Subject: Re: [openpgp] Disabling compression in OpenPGP
From: ianG <[email-masked]>
To: [email-masked]
Date: Thu, 20 Mar 2014 13:57:46 +0000
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>

On 19/03/2014 22:58 pm, Jon Callas wrote:
> 
> On Mar 19, 2014, at 3:04 PM, Gregory Maxwell <[email-masked]> wrote:
> 
>> 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."
> 
> It is! It's a really cool failure mode, and I think you should write it up and submit it to some security conference.
> 
> However, as I said, it's an exception case. 

Is there a sense that this could be more traumatic at small packets?
Could we set a limit say 100b under which packets aren't compressed?

Actually I think not because the attack is about comparison amongst
results of different packets.  The encrypting/compressing agent only
knows about its one packet, it knows nothing about the other packets.
So it cannot know about the effect of compression on the other packet,
and how one ends up being markedly different to another.

If I get it right, it all comes back to the (hidden? agreed?) assumption
of length.  What is our preference, to meet some assumption about
length?  Or to not meet it?

Perhaps a comment needs to be put in the document "We make no claims as
to the preservation of length.  Compression can result in leaking
information which can be illuminating in known-plaintext and
multi-packet scenarios."

iang