简短的回答：不要出汗。在大多数情况下，填充方法的选择并不重要。

更长的答案：为什么没关系。 只要您使用正确的加密设计实践——特别是，只要密文得到正确的身份验证——我不知道填充的选择会以何种方式影响安全性（有一个例外，见下文）。

正如@Thomas 解释的那样，如果您未能对密文进行身份验证，那么确实可能会受到攻击。再说一次，如果密文没有得到正确的认证，你可能还有很多其他的问题，所以你不应该把这归咎于填充方案。密码学家知道，如果你加密了一些东西，你真的应该验证密文；不这样做是一个典型的新手错误，可能会导致严重的安全漏洞。

简而言之，如果您遵循良好的加密实践，填充的选择对安全性应该没有太大影响（如果您没有遵循良好的加密实践，您可能会遇到更大的问题）。

例外：它确实重要的情况。 好的，现在我们来看看细则。这就是我承认上述内容有点过于简单化的地方。在一种情况下，填充的选择可能对安全性非常重要：对流量分析的抵抗力。

加密不会隐藏被加密消息的长度：加密消息通常会显示被加密消息的长度（或近似长度）。在某些情况下，这可能会带来很大的问题。例如，在某些情况下，泄露长度信息会泄露整个商店：它会泄露您试图保密的内容。（例如，参见Chen 等人对 SSL 加密的 Web 应用程序的惊人的侧信道攻击。除其他外，他们表明，在用户输入 Web 搜索查询时观察网络数据包长度的窃听者可以推断出搜索的内容。查询是。我认为谷歌解决了这个问题，但这是一个令人惊叹的、令人大开眼界的例子，说明了以前已知的一般风险。）

如果您处于消息长度显示敏感信息的环境中，那么您就有问题了。标准的防御是在加密之前填充消息，以便密文长度不会透露任何有关消息长度的信息。一种方法是在加密之前将所有消息填充到固定长度。另一种（不太安全）的方法是添加随机长度的填充，具有足够的随机填充以使随机噪声模糊信号并防止攻击者学习足够的长度信息来造成任何伤害。因此，在我们需要防止流量分析的情况下，填充方案的设计变得至关重要，而标准的填充方案可能还不够：您可能需要做一些特别的事情。

填充可能存在一些问题：

• 随机填充可用于某种隐写术，允许损坏的发件人泄漏秘密数据以供第三方使用。在正常情况下，这不是一个大问题，但看起来仍然很糟糕。

• 对填充处理有一些攻击。也就是说，接收者可以解密并找到一个有效的填充，或者一些看起来很随机的垃圾。如果接收者在后一种情况下报告了一个明显的错误代码，那么这是一个“填充预言”，它可以用来攻击系统。Vaudenay 在 2002 年详细解释了这一点，并且是八年后ASP.NET padding oracle 攻击的基础。

无填充加密模式（例如 CTR）避免了填充的复杂性和网络开销。