Encryption leaks data length: for any given input message, the encrypted output will have a length which will be close to that of the input message. If using a padding-less encryption mode (e.f. CFB, as used in the OpenPGP format that PGP implements), then the cleartext data length can be recovered exactly. This is a property common to all encryption systems, and it is the reason why traffic analysis is a powerful attack tool.
Compression does not qualitatively change this issue, but it can worsen it. Compression makes data length dependent on data contents, so it can leak extra information. For instance, consider a payment system for some Web site: the customer sends his credit card information to the site, which then forwards the credit card number, along with the transfer amount and the current date, to a partner bank. Suppose that each such message is to be encrypted with OpenPGP, and has a fixed-length format (16 characters for the credit card number, and so on). The fixed length is meant to deter traffic analysis. However, with compression active, this is not so: the message will be shorter if the amount or the current date contains digit patterns which are also found in the credit card number. The attacker knows the current date, and can infer the transfer amount (it must match the price of one of the items which are sold on the site), so the leak can be exploited to gain some partial information on the credit card number.
It is all a matter of context. The Web and HTTPS offer some characteristics which make exploitation quite effective:
- The victim's browser includes the target secret (a cookie) in each request it sends, at a predictable place, and always the same value.
- The attacker can inject hostile code (Javascript) which can arrange for triggering requests at will, hundreds of them, without anything showing up on the user's screen.
- The hostile code from the attacker gets to add a lot of data of its own choosing along with the secret value. This is a chosen-plaintext attack.
Thanks to these characteristics, CRIME works (well, not anymore since browsers don't support TLS-level compression, but it used to work). But they don't apply to usual OpenPGP usage contexts. PGP was meant for emails, with a human painfully typing each message, and another human reading them at the other end. No hostile code, no or very little chosen plaintext, and the fuzziness of human language moving around secret values.
Hence, we can say that the normal usage scenario of PGP is such that compression does not substantially degrades security, which justifies its use by default. Although, to be fair, PGP does not compress by default because it is usually safe; it compresses by default because that's what it did twenty years ago, and old habits die hard. In the beginning, the compression was there to make up for the overhead of encryption, mostly the extra few hundred bytes for the asymmetric cryptography, and the +33% size increase implied by Base64 encoding. With recent hardware and networks, this is hardly relevant; PGP compresses out of Tradition more than anything else.
To conclude, an enlightening story. In early 1942, the US Navy was trying to prepare for the next Japanese attack after Pearl Harbor and the battle of the Coral Sea. The target was known under a code name in the Japanese communications. To confirm its identification, the Americans deliberately sent fake messages among the normal transit of routine messages, in order to see that information show up in the Japanese stream and correlate it. In this specific case, they claimed that their base at Midway had a broken distiller. The Japanese encoded transmissions reported that the target for the next attack was short on water. This crucial information was instrumental to the Japanese defeat, after which it all went downhill for Japan until the end of World War II. (Even Wikipedia has pointers on this anecdote, so it is not only a nice story, but it might even be true.)
This is a chosen-plaintext attack all right, coupled with traffic analysis. The important point, for the present discussion, is that routine messages are computer-like: though it was in 1942, military behaviour can be considered to emulate a mindless computer. The chosen-plaintext attack could be pulled off because it took place in a context where the victim (here, the Japanese communication network) could reliably be made to relay chosen information, in its own coding system, with a predictable format.
The same applies to PGP. If you use PGP in the traditional way, for handcrafted text messages, to communicate from a human brain to another, then compression is safe. If you use PGP in an automated way, to send lots of messages in a predictable format with contents that can mostly be guessed or even chosen by attackers, then compression may substantially increase your security issues.
