Compress first. Once you encrypt the file you will generate a stream of seemingly random data, which will be not be compressible. The compression process depends on finding compressible patterns in the data.
If your encryption algorithm is any good (and AES, with a proper chaining mode, is good), then no compressor will be able to shrink the encrypted text. Or, if you prefer it the other way round: if you succeed in compressing some encrypted text, then it is high time to question the quality of the encryption algorithm…
That is because the output of an encryption system should be indistinguishable from purely random data, even by a determined attacker. A compressor is not a malicious attacker, but it works by trying to find non-random patterns which it can represent with fewer bits. The compressor should not be able to find any such pattern in encrypted text.
So you should compress data first, then encrypt the result, not the other way round. This is what is done in, e.g., the OpenPGP format.
Compress first. If you encrypt then your data turns into (essentially) a stream of random bits. Random bits are incompressable because compression looks for patterns in the data and a random stream, by definition, has no patterns.
Of course it matters. It's generally better to compress first and then to encrypt.
ZLib uses Huffman coding and LZ77 compression. The Huffman tree will be more balanced and optimum if it's performed on plain text for instance and so the compression rate will be better.
Encryption can follow after compression even if the compression result appear to be "encrypted" but can easily be detected to be compressed because the file usually starts with PK.
ZLib don't provide encryption natively. That's why I've implemented ZeusProtection. The source code is also available at github.
从实际角度来看，我认为您应该首先压缩，因为许多文件都是预先压缩的。例如，视频编码通常涉及大量压缩。如果您加密该视频文件然后对其进行压缩，则它现在已被压缩两次。第二次压缩不仅会得到很低的压缩率，而且再次压缩会占用大量资源来压缩大文件或流。作为 Thomas Pornin 和 Ferruccio表示，由于加密文件的随机性，加密文件的压缩无论如何可能没有什么效果。
From a practical perspective, I think you should compress first simply because many files are pre-compressed. For example, video encoding usually involves heavy compression. If you encrypt this video file then compress it, it has now been compressed twice. Not only will the second compression get a dismal compression ratio, but compressing again will take a great deal of resources to compress large files or streams. As Thomas Pornin and Ferruccio stated, compression of encrypted files may have little effect anyway because of the randomness of the encrypted files.
I think the best, and simplest, policy may be to compress files only-as-needed beforehand (using a whitelist or blacklist), then encrypt them regardless.
发布评论
评论（6）
先压缩一下。加密文件后，您将生成看似随机的数据流，该数据流不可压缩。压缩过程取决于在数据中找到可压缩模式。
Compress first. Once you encrypt the file you will generate a stream of seemingly random data, which will be not be compressible. The compression process depends on finding compressible patterns in the data.
加密前压缩肯定会更节省空间，但同时安全性较低。这就是为什么我不同意其他答案。
大多数压缩算法使用“神奇”文件头，这可用于统计攻击。
例如，存在CRIME SSL/TLS 攻击。
Compression before encryption is surely more space efficient but in the same time less secure. That's why I would disagree with other answers.
Most compression algorithms use "magic" file headers and that could be used for statistical attacks.
For example, there is a CRIME SSL/TLS attack.
如果您的加密算法很好（并且具有适当链接模式的 AES 也很好），那么任何压缩器都无法缩小加密文本。或者，如果您更喜欢相反的方式：如果您成功压缩了一些加密文本，那么就该质疑加密算法的质量了……
那是因为加密系统的输出应该与纯随机数据没有区别，即使是坚定的攻击者。压缩器不是恶意攻击者，但它的工作原理是尝试找到可以用更少的位表示的非随机模式。压缩器不应该能够在加密文本中找到任何此类模式。
因此，您应该首先压缩数据，然后加密结果，而不是相反。这是在 OpenPGP 格式 中完成的。
If your encryption algorithm is any good (and AES, with a proper chaining mode, is good), then no compressor will be able to shrink the encrypted text. Or, if you prefer it the other way round: if you succeed in compressing some encrypted text, then it is high time to question the quality of the encryption algorithm…
That is because the output of an encryption system should be indistinguishable from purely random data, even by a determined attacker. A compressor is not a malicious attacker, but it works by trying to find non-random patterns which it can represent with fewer bits. The compressor should not be able to find any such pattern in encrypted text.
So you should compress data first, then encrypt the result, not the other way round. This is what is done in, e.g., the OpenPGP format.
先压缩一下。如果您加密，那么您的数据就会变成（本质上）随机位流。随机位是不可压缩的，因为压缩会寻找数据中的模式，而根据定义，随机流没有模式。
Compress first. If you encrypt then your data turns into (essentially) a stream of random bits. Random bits are incompressable because compression looks for patterns in the data and a random stream, by definition, has no patterns.
当然这很重要。通常最好先压缩然后加密。
ZLib 使用霍夫曼编码和 LZ77 压缩。例如，如果在纯文本上执行，霍夫曼树将更加平衡和最佳，因此压缩率会更好。
压缩后可以进行加密，即使压缩结果看似“加密”，但很容易被检测到已压缩，因为文件通常以 PK 开头。
ZLib 本身不提供加密。这就是我实施 ZeusProtection 的原因。源代码也可从 github 获取。
Of course it matters. It's generally better to compress first and then to encrypt.
ZLib uses Huffman coding and LZ77 compression. The Huffman tree will be more balanced and optimum if it's performed on plain text for instance and so the compression rate will be better.
Encryption can follow after compression even if the compression result appear to be "encrypted" but can easily be detected to be compressed because the file usually starts with PK.
ZLib don't provide encryption natively. That's why I've implemented ZeusProtection. The source code is also available at github.
从实际角度来看，我认为您应该首先压缩，因为许多文件都是预先压缩的。例如，视频编码通常涉及大量压缩。如果您加密该视频文件然后对其进行压缩，则它现在已被压缩两次。第二次压缩不仅会得到很低的压缩率，而且再次压缩会占用大量资源来压缩大文件或流。作为 Thomas Pornin 和 Ferruccio表示，由于加密文件的随机性，加密文件的压缩无论如何可能没有什么效果。
我认为最好、最简单的策略可能是仅根据需要事先压缩文件（使用白名单或黑名单），然后无论如何对它们进行加密。
From a practical perspective, I think you should compress first simply because many files are pre-compressed. For example, video encoding usually involves heavy compression. If you encrypt this video file then compress it, it has now been compressed twice. Not only will the second compression get a dismal compression ratio, but compressing again will take a great deal of resources to compress large files or streams. As Thomas Pornin and Ferruccio stated, compression of encrypted files may have little effect anyway because of the randomness of the encrypted files.
I think the best, and simplest, policy may be to compress files only-as-needed beforehand (using a whitelist or blacklist), then encrypt them regardless.