On 19/03/2014 22:58 pm, Jon Callas wrote:
On Mar 19, 2014, at 3:04 PM, Gregory Maxwell <gmaxwell(_at_)gmail(_dot_)com>
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
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp