This came up in an IRC discussion on freenode, and now I"m curious.
The idea is that someone wants to determine whether or not encryption alone, or compression+encryption (with gpg/pgp being the primary encryption system), provides better 'security' of the files.
Since I am not an expert in cryptography or cryptographical security, I'm wondering whether there's anything to back up either option over the other.
(Because nothing is truly 'secure' I'm using single quotes here)
There are several factors that come into play. The first is that encryption should hide patterns: if you have a file that contains the same content repeated several times over, encryption should hide this fact. If you have a weak encryption scheme, that leaks some information about patterns in the plaintext in its ciphertexts, then compression can help reduce the amount of information that leaks through. At least, that'st the classical theory. Any encryption scheme that's good enough to be used nowadays should take care of patterns all by iself though, compression or no compression (related tip: never use ECB mode directly). So the classical argument for compression before encryption is no longer that relevant (and compression after encryption is pointless in just about every case).
Another "classical" argument is that the chances of breaking a cipher increase with the amount of ciphertext you have to work with. So if you compress your messages before sending, you give an attacker less material to work with. Again, for any cipher secure under modern notions you should not have to worry about this. You should update your algorithms and key sizes every now and then according to the latest recommendations, rotate keys etc. - but the impact of compression on this will be minimal. Also if you encrypt each message under a per-message key and then transport this key bey encrypting it under a key-encrypting-key, which is a pretty standard thing to do (especially when public-key crypto is involved), you're controlling how much ciphertext gets sent out under any one key far better than you could by fiddling with compression.
The next point is that you might want encryption to hide the length of your ciphertext to some extent too. It's not too hard to gain some "metadata" about what someone is doing on a TLS connection by observing packet lengths and frequencies. Compression before encryption can help reduce the strength of the "signal" in some cases, but if you're worried about traffic analysis then you probably should be doing other things like padding to a fixed length - again, compression can make a bad situation a bit less bad, but it's not going to turn a bad situation into a good one.
Finally, you may have heard that compression within the TLS protocol will be abolished and banned in v1.3, or at least that was the case when I last read the draft. This is not to do with compression in general but because the specific way encryption, padding, MACs and compression interacted in TLS 1.2 and earlier standards had some vulnerabilities (CRIME, BEAST etc.). That doesn't mean that you can't compress at a higher (application) level or that compression weakens encryption in general, just that it has no place in the actual encryption module, at least not in the way it's done in TLS at the moment.
In response to comments asking further questions, here are two examples of how compression can help or hurt you.
Example 1 You're applying for a job and you agree to send your best friend an encrypted message telling you if you got it or not. Because you work in IT, a plain "yes" or "no" will not do - it has to be an animated GIF, so you prepare two files yes.gif and no.gif, and because you're worried about someone just looking at the filesize of your ciphertext you make them both exactly 64KB. But the yes.gif is full of colours and ponies and rainbows and when compressed, 60KB large - the no.gif is a more demure slow black/white animation and compresses down to 4KB. Your encryption program automatically applies compression before encryption. In this case, compression ruins your security completely.
Example 2 You've given up on the animated GIFs and agree that next time you want to meet your friend, you'll give him an encrypted e-mail simply saying "Let's meet next [day of week]." Your encryption program encrypts in 8-character (64 bit) blocks. If your message is "Let's meet next Monday." it fits nicely into 3 blocks, if it's "Let's meet next Wednesday." that's 4 blocks. Failed again. In this case, "mentally compressing" all days into their first three letters ("Let's meet next WED.") would have saved you.
In summary - compression does not generically help or harm encryption; if you typically have to deal with messages of similar lengths but varying levels of entropy/compressability then it might well do more harm than good.
The CRIME attack works because of a set of very specific circumstances that involve compression as one ingredient, but should not be applicable to file storage.
Compression is not security at all. You may be confusing compression with steganography data hiding but regardless, neither provides true security but instead merely hides things. Encryption of course does secure your data.
From Wiki:
Brute-force attacks can be made less effective by obfuscating the data to be encoded, something that makes it more difficult for an attacker to recognize when he/she has cracked the code. One of the measures of the strength of an encryption system is how long it would theoretically take an attacker to mount a successful brute-force attack against it.
This may be where the confusion starts. You might think that 'oh hey when I use winzip and look at the hex data it all looks different thus I have created a tiny layer of obscurity, right?' Wrong! Unless you are using an unique method of obscurity all you are doing is slowing down the process of checking the brute force attempt by an insanely small amount of time.
This is because every file has what is called a file signature (so that the operating system can make sense of all the data) so unless you either create your own unique file signature or hide your data within some other signature there is no enhancement gained in just changing one signature for another.
Multiple attacks with very evocative names have shown that compression can induce vulnerability by leaking infos about the plaintext:
Basically, if you can control some part of the plaintext, you can guess other parts of the plaintext by looking at the size of the ciphertext (because compression will be more effective when you match existing patterns in the plaintext).
Imagine that someone is trying to brute force decrypt a file, and when a certain password is tried, an obvious English text file pops out.
Or suppose that the same exercise is tried, but all the bytes in the text file were shifted forward 79 places before encryption.
The second approach is stronger, even though obfuscation (shifting bytes) is NOT encryption.
The same may be true for compressing a file before encrypting it.
