6
$\begingroup$

Is it better to encrypt a plain text file before compression, or vice versa?

$\endgroup$
  • 1
    $\begingroup$ One common test of the quality of encryption is that you can't compress it. That being said, you should stay away with compression from secret data (i.e. don't try to compress plain passwords). $\endgroup$ – SEJPM Mar 15 '16 at 22:35
  • $\begingroup$ Based on answers below, one might argue that compressing after encrypting is almost always better than the reverse :) $\endgroup$ – Joel Cornett Oct 13 '18 at 1:56
16
$\begingroup$

Neither:

  • Encrypting first and then compressing does not work.

  • Compressing first can leak information about plaintext content through the ciphertext length, as poncho mentioned in comments to another answer.

Specifically, compression allows an attacker who can control parts of the message that is encrypted to reveal things about the other, secret parts, like cookies in the case of web traffic. It is most dangerous in a live protocol like TLS. Some forms of compression (e.g. truly constant bitrate lossy video/audio compression) may be immune to such attacks (but even then there might be side channel attacks due to the compression).

In most cases you should just encrypt the uncompressed data and be done with it.

Data storage and transmission is usually cheap enough. If you cannot live without compression, you must do it first, but then you have to really know what you are doing and likely accept at least some loss of security.

$\endgroup$
  • $\begingroup$ Compression is routinely used in the real world and a correct answer should address this. $\endgroup$ – user9070 Jun 17 '16 at 11:42
  • $\begingroup$ @TruthSerum, the recommendation with regard to e.g. TLS is to disable compression. Similarly e.g. RC4 is also used in the real world, but that does not change the fact that it should not be. I'll edit in some specifics, though. $\endgroup$ – otus Jun 18 '16 at 8:32
3
$\begingroup$

Make sure to also check out the CRIME and BREACH attacks, which are made possible by protocols using compression inside encryption.

$\endgroup$
2
$\begingroup$

It is better to compress before encrypting.

Any proven block cipher will reduce the data to a pseudo-random sequence of bytes that will typically yield little to no compression gain at all.

Additionally, encrypting compressed data can potentially also carry the added benefit of making statistical analysis harder (though this of course does depend on the compression algorithm and whether it inserts any predictable metadata), although this isn't particularly relevant with a block cipher and a sensible operation mode (i.e. not ECB)

$\endgroup$
  • 9
    $\begingroup$ Encrypting compressed data can also potentially leak information about the plaintext (such as how compressible it was) to the attacker. $\endgroup$ – poncho Mar 16 '16 at 3:46
  • 4
    $\begingroup$ And this can be used to completely defeat encryption, if an attacker can control part of the message that gets encrypted. $\endgroup$ – Stephen Touset Mar 16 '16 at 20:17
  • $\begingroup$ @StephenTouset A chosen plaintext attack isn't universally applicable to all ciphers. Additionally, if the attacker can do that, I would be interested to see a situation where compression + encryption of the chosen plaintext makes the attack easier than just encryption. $\endgroup$ – Olipro Mar 17 '16 at 1:22
  • 3
    $\begingroup$ A chosen-plaintext attack in the style of CRIME and BREACH are applicable independently of the cipher, as they attack information leaked by the compression algorithm. Both of those are clear instances of exactly the kind of example you are interested in. $\endgroup$ – Stephen Touset Mar 17 '16 at 1:47
1
$\begingroup$

It depends on the operational constraints. If you have storage or bandwidth constraints and need to compress data, you should compress first then encrypt (compressing an encrypted text doesn't make sense as the cryptogram is a random series of bytes provided the algorithm is good - so the output won't compress well). Compression will also have a performance penalty, something that should be taken into account when selecting a compression algorithm.

$\endgroup$
-1
$\begingroup$

Compress and then encrypt is better. Data compression removes redundant character strings in a file. So the compressed file has a more uniform distribution of characters.

This also provides shorter plaintext and ciphertext, which reduces the time spent encrypting, decrypting and transmiting the file.

By comparison, encrypting and then compressing is innefficient.

$\endgroup$
  • 1
    $\begingroup$ Actually with modern encryption schemes it doesn't matter anymore whether or not there are redundancies in the plaintext (except for maybe processing overhead, but then compression also isn't free). $\endgroup$ – SEJPM May 18 at 17:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.