填充是一种加密大小的消息的方法，否则分组密码将无法解密；这是加密和解密之间的约定。如果您的输入消息始终具有可以使用您的加密模式处理的长度（例如，您的消息始终具有 16 的长度倍数），那么您不必添加填充 -只要在解密期间，您不要尝试查看当没有填充时。如果您的某些消息需要填充，那么您将必须系统地添加某种填充，否则解密将是模棱两可的。

填充不会增加安全性。实施不当的填充管理可能会泄漏信息（填充预言），因此您必须小心您的实施——最好不要自己动手。

（当然，最好使用不需要任何填充并包括急需但被忽视的完整性检查的加密模式；这意味着GCM或EAX，而不是 CBC。）

这完全取决于您要加密的内容。如果您要加密长度始终为 32 字节（或块大小的倍数）的数据，则根本不必使用填充。

如果纯文本是任意长度的，那么您必须填充文本并使用一种机制，以便在解密时能够将数据与填充分开。

假设您正在使用填充方案，如果缺少一个字节，则使用 01 填充，如果缺少 2 个字节，则使用 02 02 等等。

您还必须为 16 字节文本添加填充，否则如果您解密像

01 02 03 05 06 01 02 03 05 06 06 01

您将无法知道这是否是 15 字节文本：

01 02 03 05 06 01 02 03 05 06 06 + 01

填充未填充的 16 字节文本：

01 02 03 05 06 01 02 03 05 06 06 01

.

通过知道您始终填充数据，无论长度如何，上述问题都得到了解决。

向块大小的倍数的消息添加填充不是“强制性的”，但大多数实现都会这样做。PKCS#5 填充规定添加一个字节块，全部设置为零，以告诉算法它实际上拥有所有已传输的块。当可以调用实现来加密任何长度的任何内容并通过“不可靠”的传输方法发送它时，这很有帮助。当使用具有自己的错误检查的通信层时，例如 TCP，并且当您知道未填充的消息始终是所用块大小的精确倍数时，它是多余的。