Can compressed data be made to look like random data?

Question

I saw the question "Decryption honeypots" and realized that if the message was compressed before being encrypted, then checking compressibility would not help you identify the decoded message.

So if the message is compressed by a known method is there a fast way to determine if it is a compressed message (right key) or random data (wrong key), without attempting the decompression method every time?

Edit: I was thinking about a scenario with large (1 gigabyte uncompressed), relatively verbose files like XML which can have a compression ratio of 8:1 An Analysis of XML Compression Efficiency, using a compression algorithm with an output that is nearly uniform. Also with padding on the compressed message to avoid attacks like CRIME as mentioned in the answer below (it seems hilarious to zip something smaller then pad it back to the same size, but this is to hopefully make it harder to decrypt).

Answer 1

TL;DR: yes it can look more random than the plaintext message itself, but it won't help you against crypt-analysis and in the worst case it may introduce vulnerabilities.

---

I guess the most boring but most effective way is simply to look for meta data within the compressed message. E.g. the precise compression mechanism and compression level may well be within the decrypted message.

---

Generally you assume that the protocol is known (Kerckhoff's principle). Note that finding out the compression used is usually not hard, and you only have to do so for a single message.

Once you know the compression method checking the correctness of decryption is as easy if not easier; you can always first decompress before checking the correctness of the decrypted message.

Decompressing a message may well be faster than decrypting it. Performing the compression is usually slower as it needs to look for patterns. Compression will only add a single additional step to the crypt-analyst; it's not something you do to make your protocol more secure against brute force attacks. Basically you could compare it to adding a single bit to the security level at most.

An attacker may always use compression on a (set of possible) known plaintext and compare against that, resulting in a meet-in-the middle attack.

---

Compression in cryptography is a very dangerous thing. Some plaintext compress better than others and smaller plaintext generally lead to smaller ciphertext. So even if the plaintext is the same size, compression may confer details about the plaintext to an attacker. Take for instance a look at the CRIME attack against TLS for an example of this.

---

Compressed or inflated data usually does not look like random data, and it is a very dangerous to see it as a security feature. It is much more likely to add insecurity than security when trying to encrypt messages.

---

Important note: this answer is only valid for modern ciphers where frequency analysis of the ciphertext is not an attack vector.

Answer 2

I saw the question "Decryption honeypots" and realized that if the message was compressed before being encrypted, then checking compressibility would not help you identify the decoded message.

This premise strikes me as false. Here's how I think of it. First, you need to model the problem in terms of probability distributions. Plaintext messages are modeled as random variable that obeys some distribution, generally one that shows many statistical biases.

One of the goals of cryptography, seen in this light, is to design efficient functions that, when fed inputs sampled from such biased distributions, produce output distributions that cannot efficiently be told apart from some ideal high-entropy distribution (often an uniform random distribution or one isomorphic to such). This is generally a requirement for encryption schemes—ciphertexts should be indistinguishable from random data, so that even an adversary who has excellent hypotheses about the input plaintext distribution may not use ciphertexts to support or infirm such hypotheses. (See: semantic security.)

But compression functions have no such requirement. On the contrary, they're actually supposed to produce biased outputs from biased inputs. The efficiency of a compression function is how closely it approximates an information-theoretically optimal code—a code that is tailor-fitted to the source distribution so that more probable source events are coded into shorter messages. This means that a good compression function should allow you to "read off" a message's approximate source probability from its compressed length—something that has been exploited in attacks where, for example, compress-then-encrypt VoIP protocols allow recovery of words spoken on a call.

So optimally compressed data just cannot "look random" compared to how the plaintexts look. Its distribution must correlate in meaningful ways with the uncompressed message distribution. And this is best appreciated by thinking about it in the aggregate—in terms of probability distributions over message spaces, not individual messages.

So if the message is compressed by a known method is there a fast way to determine if it is a compressed message (right key) or random data (wrong key), without attempting the decompression method every time?

Suppose you know the prefix-free code that the messages were compressed with. That might be enough to discard many keys simply because they would decompress the ciphertext to a message with a proper prefix that the code does not allow. Or if you have a corpus of many ciphertexts, you could test whether their decryptions with the candidate key, in the aggregate contradicts the prefix-free property. "Compressed" is often popularly associated with "random," but that's sloppy thinking.