[Cryptography] Summary: compression before encryption
stephan.neuhaus at zhaw.ch
Mon Jan 12 03:14:38 EST 2015
thank you very much for your many answers; I'll summarise them here.
The question was whether compression before encryption helps security or
does more harm than good.
The consensus seems to be that while "it depends", it is more likely
that compression does not help security and might well harm it.
The reason is that compression may enable oracle attacks such as CRIME
(see https://en.wikipedia.org/wiki/CRIME; the first respondent to give
that link was Philipp Jovanovic philipp at jovanovic.io.) In this
chosen-plaintext attack, the attacker learns about a secret S by
observing the length of the resulting ciphertext. The attacker uses a
CSRF to inject a plaintext P that is compressed together with the secret
S and then encrypted: Cipher = E(Compress(P, S)). Now the attacker
observes Cipher' = E(Compress(P', S)). If the size of Cipher' is less
than the size of Cipher, then P' and S compressed better than P and S.
Knowing the compression algorithm allows the attacker to learn something
about, and eventually discover, S.
Where such attacks are feasible, compression should be disabled. This
protects against CRIME even in the presence of CSRFs.
Another argument that was advanced was that if E(Compress(P)) were more
secure than E(P), then E would have a problem. Technically, modern
ciphers have "to be resistant not just to known-plaintext but to
chosen-plaintext attacks, so hiding plaintext patterns doesn't really
get you much" (Peter Gutmann pgut001 at cs.auckland.ac.nz).
Another correspondent (natanael.l at gmail.com) raised the point that the
presence of plaintext patterns in an RC4-encrypted stream would allow
one to uncover biases in the key stream and ultimately the key, and
compressing the plaintext would hide these patterns. But while that's
strictly true, surely that's just a matter of degree, and you're putting
your broken-down cart in front of your wheezing old horse. (See also
Another respondent (albert at puigsech.com) argued that
Encrypt-then-Compress was also an option ("has its pros"), but I'm
inclined to dismiss that since compression involves no secret, and so I
don't see how it can increase security post-encryption.
Finally, if injection is unlikely but compression highly beneficial for
reasons having nothing to do with security (for example, if all you want
is an encrypted channel to transfer your backups; the more general case
being a one-way push or pull operation), then compression is very likely
fine (noted by grarpamp at gmail.com).
In summary: compression *as a security device* is unlikely to benefit
you, but likely to do you harm, so when in doubt, leave it out.
More information about the cryptography