您应该在加密之前进行压缩。

加密将您的数据转换为高熵数据，通常与随机流无法区分。压缩依赖于模式以获得任何尺寸减小。由于加密会破坏此类模式，因此如果将压缩算法应用于加密数据，压缩算法将无法大大减少（如果有的话）大小。

如果攻击者只能控制未压缩的明文，加密前的压缩也会略微增加您对差分密码分析（和某些其他攻击）的实际抵抗力，因为结果输出可能难以推断。

编辑：我在几年后进行编辑，因为这个建议在交互式案例中实际上很差。在大多数情况下，您不应该在加密之前压缩数据。在攻击者可以交互地将字符串放入其他未知的明文数据流的情况下，可以使用称为“压缩预言”的边信道攻击方法来推断明文数据。诸如 CRIME 和 BREACH 等对 SSL/TLS 的攻击就是这样的例子。

如果您在加密后进行压缩并且压缩效果很好（即它确实将长度减少了不可忽略的数量），那么您可以放弃加密，它非常弱。加密文本应该与随机性无法区分；即使是加密严重的数据通常也无法压缩。

因此，加密前先压缩。这就是为什么处理加密的协议通常包含一些对压缩的支持，例如OpenPGP（第 5.6 节）和SSL/TLS。在某些情况下，压缩可能会泄漏有关机密数据的信息（因为压缩会根据数据减少长度，并且加密长度或多或少与明文长度匹配）；这就是对 SSL/TLS 的新 CRIME 攻击背后的想法。

边缘例外：如果您使用 OpenPGP 加密消息然后“ACSII Armor”结果，即使用 Base64 对其进行编码，则此编码会将数据放大 34%：3 个字节变为 4 个字符（加上奇数换行符）。使用DEFLATE压缩将有效地取消这种放大（感谢 Huffman 代码）。这是加密后压缩有用的一个例子——但实际上，这比 Base64 压缩更多，而不是加密压缩。

我建议先压缩数据，然后再加密。

1. 压缩算法可能会受益于数据结构的知识，并且该结构将被加密伪装。一个例子是 mp3，它只能压缩声音数据。

2. 您将不得不加密更少的数据。而当您第一次加密然后压缩时，您将不会获得任何加速。

两者都不是：在加密期间使用旨在安全地执行这两种操作的加密工具进行 压缩，例如GPG/OpenPGP。

这基本上是Thomas Pornin 的回答，只是更直接，所以匆忙的读者不要误解 Thomas Pornin 在他的回答中解释的微妙之处。这个问题表达了错误的二分法。如果 OP（和读者）认为第一步和第二步是执行两个不同的工具，比如gzipand gpg：

1. 如果你先加密，压缩不会做太多，除了挤出@ThomasPornin提到的“ASCII 盔甲”的 Base64 34% 膨胀。

2. 如果你先压缩，加密的安全性会降低，容易受到@ThomasPornin提到的攻击。