I have the assumption there is no added protec开发者_运维技巧tion at all.
There is no difference in the security provided, but because of the way compression algorithms work, you are probably going to get better compression if you compress first then encrypt.
Compression algorithms exploit statistical redundancies (such as those that exist in natural language or in many file formats) in the data which should be eliminated when you encrypt it, therefore an encrypted message shouldn't be able to be compressed all that well.
From the wikipedia article:
However, lossless data compression algorithms will always fail to compress some files; indeed, any compression algorithm will necessarily fail to compress any data containing no discernible patterns. Attempts to compress data that has been compressed already will therefore usually result in an expansion, as will attempts to compress all but the most trivially encrypted data.
Warning: if an attacker controls part of the plaintext that gets compressed, and can observe the size of the resulting encrypted ciphertext, they may be able to deduce the rest of the plaintext, by adjusting the part that they control until the length of the ciphertext decreases (which implies that there was some repetition between the part of the plaintext they control and the secret part of the plaintext).
See https://en.wikipedia.org/wiki/CRIME for example.
Encryption works better on short messages, with a uniform distribution of symbols. Compression replaces a message with a non-uniform distribution of symbols by another, shorter sequence of symbols that are more uniformly distributed.
Therefore, it's mathemathically safer to compress before encryption. Compression after encryption doesn't affect the encryption, which remains relatively weak due to the non-uniform distribution of plaintext.
Of course, if you use anything like AES256, and the NSA isn't after you, this is all theory.
There is no added security (as compression is not a security mechanism), but a properly encrypted message shouldn't be easily compressible (i.e. rule of thumb: if you can significantly compress an encrypted message, something is wrong).
Therefore, compress then encrypt.
Look here: Super User thread about compression && encryption or the other way around
They have a complete and detailed answer to your question (witch is compress then encrypt, by the way).
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. If the encryption is done properly then the result is basically random data. Most compression schemes work by finding patterns in your data that can be in some way factored out.
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.
According to William Stalling’s book “Network Security Essentials: Applications and Standards, 4th edition”, published by Pearson, At chapter 7, Page 227:
As a default, PGP compresses the message after applying the signature but before encryption. This has the benefit of saving space both for e-mail transmission and for file storage. The placement of the compression algorithm, indicated by Z for compression and Z –1 for decompression in Figure 7.1, is critical.
The signature is generated before compression for two reasons:
- It is preferable to sign an uncompressed message so that one can store only the uncompressed message together with the signature for future verification. If one signed a compressed document, then it would be necessary either to store a compressed version of the message for later verification or to recompress the message when verification is required.
- Even if one were willing to generate dynamically a recompressed message for verification, PGP’s compression algorithm presents a difficulty. The algorithm is not deterministic; various implementations of the algorithm achieve different tradeoffs in running speed versus compression ratio and, as a result, produce different compressed forms. However, these different compression algorithms are interoperable because any version of the algorithm can correctly decompress the output of any other version. Applying the hash228 CHAPTER 7 / ELECTRONIC MAIL SECURITY function and signature after compression would constrain all PGP implementations to the same version of the compression algorithm.
2. Message encryption is applied after compression to strengthen cryptographic security. Because the compressed message has less redundancy than the original plaintext, cryptanalysis is more difficult.
Although those reasons are explained for PGP algorithm, but simply they are expandable to other approaches. So it's better to compress before the encryption.
There is no difference in security provided.
Yep, there should be no difference in the security provided.
精彩评论