Is it better to encrypt a plain text file before compression, or vice versa?
-
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$– SEJPMCommented 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$– Joel CornettCommented Oct 13, 2018 at 1:56
5 Answers
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.
-
1$\begingroup$ Compression is routinely used in the real world and a correct answer should address this. $\endgroup$– user9070Commented 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$– otusCommented Jun 18, 2016 at 8:32
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)
-
11$\begingroup$ Encrypting compressed data can also potentially leak information about the plaintext (such as how compressible it was) to the attacker. $\endgroup$– ponchoCommented 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$– OliproCommented 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
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.
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.
-
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$– SEJPMCommented May 18, 2019 at 17:07