If we want both encryption and compression during transmission then what will be the most preferable order.
- Encrypt then compress
- Compress then encrypt
Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.Sign up to join this community
You should compress before encrypting.
Encryption turns your data into high-entropy data, usually indistinguishable from a random stream. Compression relies on patterns in order to gain any size reduction. Since encryption destroys such patterns, the compression algorithm would be unable to give you much (if any) reduction in size if you apply it to encrypted data.
Compression before encryption also slightly increases your practical resistance against differential cryptanalysis (and certain other attacks) if the attacker can only control the uncompressed plaintext, since the resulting output may be difficult to deduce.
EDIT: I'm editing this years later because this advice is actually poor in an interactive case. You should not compress data before encrypting it in most cases. A side-channel attack method known as a "compression oracle" can be used to deduce plaintext data in cases where the attacker can interactively cause strings to be placed into an otherwise unknown plaintext datastream. Attacks on SSL/TLS such as CRIME and BREACH are examples of this.
If you compress after encryption and the compression does any good (i.e. it really reduces the length by a non-negligible amount) then you can ditch the encryption, it is awfully weak. Encrypted text ought to be indistinguishable from randomness; even badly encrypted data cannot usually be compressed.
Therefore, compress before encryption. This is why protocols which deal with encryption usually include some support for compression, e.g. OpenPGP (section 5.6) and SSL/TLS. In some scenarios, compression can leak information about confidential data (because compression reduces length depending on the data, and encrypted length more or less matches plaintext length); this is the idea behind the new CRIME attack on SSL/TLS.
Fringe exception: if you encrypt a message with OpenPGP and then "ACSII armor" the result, i.e. encode it in Base64, then this encoding enlarges the data by 34%: 3 bytes become 4 characters (plus the odd newline). Compression with DEFLATE will be effective at cancelling this enlargement (thanks to Huffman codes). That's a case of usefulness of compression after encryption -- but, really, that's more compression over Base64, rather than compression over encryption.
I would recommend to first compress the data and than encrypt it.
The compression algorithm might benefit from the knowledge of the data structure and that structure would be disguised by the encryption. An example would be mp3 which can only compress sound data.
you would have to encrypt less data. While when you first encrypt and then compress you would gain no speed up.
Neither: Compress during encryption with an encryption tool designed to do both securely, such as GPG/OpenPGP.
This is basically Thomas Pornin's answer just more direct, so readers in a hurry don't misunderstand the subtleties of what Thomas Pornin explains in his answer. The question expresses a false dichotomy. If the OP (and the reader) is thinking of the first and second steps being the execution of two different tools like
Compression after encryption may not do the actual function of compressing data because it is not going to reduce size much. But encryption after compressing is reduce size but it will not perform the correct functioning of encryption because attacks like CRIME can be happen.
As an example in web requests headers contain secret web cookies therefore compression of headers before encryption will reveal those secret information to out side.
Therefore it is wise to do selective compression which compress only non secret data in page and then encrypting will make sense and it will prevent the extract of secret information.