压缩然后加密，反之亦然？

我正在编写一个VPN系统，用于加密（AES256）它在整个网络上的流量（为什么当我已经有1,000,001个其他人时，为什么要写我自己的呢？嗯，我的是一个特殊的任务，适合其他人都不适合的任务）。

基本上，我想超越您，以确保我按正确的顺序进行操作。

目前，数据包只是在发送之前进行了加密，但是我想对它们进行某种程度的压缩，以对数据传输进行一些优化。不是沉重的压缩-我不想一直使CPU最大化，但是我想确保压缩将尽可能高效。

所以，我的想法是，我应该在加密之前压缩数据包，因为未加密的数据包比加密的数据包压缩得更好？还是相反？

我可能会使用zlib进行压缩。

在“超级用户”博客上阅读更多内容。

如果加密正确完成，则结果基本上是随机数据。大多数压缩方案都是通过在数据中找到可以以某种方式分解的模式来工作的，而且由于加密，现在没有了。数据是完全不可压缩的。

在加密之前先压缩。

加密前先压缩。压缩后的数据可能会因源数据的微小变化而有很大差异，因此很难执行差分密码分析。

而且，正如阿尔法先生所指出的那样，如果先加密，则结果很难压缩。

即使这取决于特定的用例，我还是建议Encrypt-then-Compress。否则，攻击者可能会从多个加密块中泄漏信息。

我们假设用户正在向服务器发送消息，而攻击者有可能在发送之前在文本中附加文本（例如通过javascript）。用户想要将一些敏感数据发送到服务器，而攻击者想要获取此数据。因此，他可以尝试将不同的消息附加到用户发送到服务器的数据上。然后，用户压缩攻击者的消息和附加的文本。我们假定使用DEFLATE LZ77压缩，因此该函数用指向首次出现的指针替换了相同的信息。因此，如果攻击者可以重现漏洞的纯文本，则压缩功能会将纯文本的大小减小为原始大小和指针。加密之后，攻击者可以计算出密码块的数量，因此，他可以查看其附加数据是否与用户发送到服务器的数据相同。即使这种情况听起来有点虚构，但这也是TLS中的一个严重的安全问题。称为CRIME的攻击使用此想法来泄漏TLS连接中的cookie，以窃取会话。

来源：http：//www.ekoparty.org/archive/2012/CRIME_ekoparty2012.pdf

我的观点是，当压缩消息时，将其投影到较低的维度，因此位数更少，这意味着压缩后的消息（假设无损压缩）在更少的位中具有相同的信息（您摆脱的冗余是多余的！ ）因此，每比特有更多的信息，因此每比特有更多的熵，但是与未压缩消息时的总熵相同。现在，随机性又是另一回事了，那就是压缩中的模式会抛出活动扳手。

压缩应在加密之前完成。用户不想花时间等待数据传输，但他/她需要立即完成数据而不浪费任何时间。

如前所述，加密前的压缩。压缩寻找可以压缩的结构。加密对数据进行加密，以避免检测到结构。通过首先压缩，您更有可能拥有较小的文件，从而减少了要传输的有效负载。无论加密与否，加密都将发挥作用，而且正如前面所指出的那样，对压缩文件执行差分加密分析可能会更加困难。

压缩可以减少信息熵。最大压缩使熵最小。对于完美加密的数据（噪声），最大和最小熵是相同的。