04.12
LP gave a very good reply to the topic of “encrypt-and-compress” or “compress-and-encrypt” , and it is worth highlighting here.
The reason why compression works is that the plaintext contains redundancy. E.g. there are certain patterns in the text, character frequencies are not uniform, etc.
On the other hand, a good encryption algorithm should exhibit good diffusion and confusion. In short, it means that encrypted data should be indistinguishable from random noise. It is obvious that this property should hold regardless of the plaintext, otherwise the encryption algorithm is broken.
Therefore, compress-and-encrypt produces smaller output with no security compromise per se, but encrypt-and-compress is like feeding random noise (whose redundancy is greatly reduced) into the compression algorithm with no obvious security benefit.
In short, encrypt-and-compress poses no obvious security benefit. Moreover, given that a good compression algorithm should be like real noise, and should not contain pattern, it follows that there will be no obvious storage benefit, either.
English
The only danger with Compress then Encrypt is that some compression algorithms *may* produce somewhat predictable data even if the initial data is not predictable, this may make partially known plaintext attacks more feasible. The most obvious would be a file header if you generated a zip file, then encrypted it, but it could be as subtle as some byte values or combinations being more likely to occur, etc.
But yes, Encrypt then Compress is pointless.
Actually there were discussions when people writing the COMPRESSION features for SMTP in RFC. Here is the information of security consideration in RFC.
RFC 3749, Compress with DEFLATE (Chapter 6)
http://www.ietf.org/rfc/rfc3749.txt
>>kuza55
I am not so good at compression, but certainly someone can tell better if it is a worthy tradeoff. =)
Now that you brought that up, it seems the risk is greatly increased, if it allows hints for cryptanalysis… umm.