16
$\begingroup$

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

$\endgroup$
2
  • 2
    $\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
    Commented Mar 15, 2016 at 22:35
  • $\begingroup$ Based on answers below, one might argue that compressing after encrypting is almost always better than the reverse :) $\endgroup$ Commented Oct 13, 2018 at 1:56

5 Answers 5

26
$\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$
2
  • 1
    $\begingroup$ Compression is routinely used in the real world and a correct answer should address this. $\endgroup$
    – user9070
    Commented Jun 17, 2016 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
    Commented Jun 18, 2016 at 8:32
5
$\begingroup$

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

$\endgroup$
3
$\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$
4
  • 11
    $\begingroup$ Encrypting compressed data can also potentially leak information about the plaintext (such as how compressible it was) to the attacker. $\endgroup$
    – poncho
    Commented Mar 16, 2016 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$ Commented Mar 16, 2016 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
    Commented Mar 17, 2016 at 1:22
  • 4
    $\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$ Commented Mar 17, 2016 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$
0
$\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
  • 2
    $\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
    Commented May 18, 2019 at 17:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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