I have the assumption there is no added protection at all.
相关问题
- “Zero out” sensitive String data in Swift
- iOS (objective-c) compression_decode_buffer() retu
- High cost encryption but less cost decryption
- Is there a public implemention of LZSS compression
- C# Rijndael decryption returns extra question mark
相关文章
- decrypt TLS 1.2 AES-GCM packet
- c# saving very large bitmaps as jpegs (or any othe
- Decrypting EnvelopedCms with non-default Algorithm
- C# AES Rijndael - detecting invalid passwords
- Sanity check SSH public key? [closed]
- How to extract zip file using dotnet framework 4.0
- data encryption and key management in c#
- What is an openssl iv, and why do I need a key and
There is no difference in security provided.
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.
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:
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).
Yep, there should be no difference in the security provided.