cryptography - 在 AES 加密中填充随机数据有好处吗？

Question

使用 AES 加密时，必须将明文填充到密码块大小。大多数库和标准使用填充，其中填充字节可以从未填充的明文长度确定。在可能的情况下使用随机填充字节有好处吗？

我正在实现一种用于存储敏感的每个用户和每个 session 数据的方案。数据通常是 JSON 编码的键值对，并且可能很短且重复。我在找 PKCS#5作为指导，但我计划使用 AES 而不是 DES3 作为加密算法。我计划为每个数据项设置一个随机 IV，并根据需要使用由用户 ID 和密码或 session ID 确定的 key 。

令我惊讶的一件事是明文的 PKCS#5 填充方案。要将密文填充为8字节块，在末尾添加1到8个字节，填充字节内容反射(reflect)填充字节数(即 01 、 0202 、 030303 ，最多为 0808080808080808 )。我自己的填充方案是在明文的前面使用随机字节，明文的最后一个字符将是添加的填充字节数。

我的推理是在 AES-CBC 模式下，每个块都是前一个块的密文的函数。这样，每个明文都会有一个随机元素，为我提供另一层保护，免受已知明文攻击，以及 IV 和关键问题。由于我的明文预计很短，我不介意将整个解密字符串保存在内存中，并切掉前后填充。

一个缺点是相同的未填充明文、IV 和 key 会导致不同的密文，从而使单元测试变得困难(但并非不可能 - 我可以使用伪随机填充生成器进行测试，并使用密码强的生成器进行生产)。

另一种情况是，要强制执行随机填充，我必须至少添加两个字节 - 一个计数和一个随机字节。对于确定性填充，最小值为 1 个字节，与明文或密文包装器一起存储。

由于像 PKCS#5 这样广受好评的标准决定使用确定性填充，我想知道是否还有其他我遗漏的东西，或者我判断的好处太高了。

Answer 1

两者，我怀疑。好处是相当小的。

您已经忘记了获取或生成加密质量随机数的运行时成本。在一种极端情况下，当可用的随机数有限时(例如，某些系统上的/dev/random)，您的代码可能需要等待很长时间才能获得更多随机字节。

在另一个极端，当您从 PRNG 获取随机字节时，如果您使用相同的随机源来生成 key ，您可能会遇到问题。如果您将加密数据一个接一个地发送给多个接收者，那么您已经向前一个接收者提供了大量有关 PRNG 状态的信息，这些信息将用于为您的下一个通信 session 选择 key 。如果您的 PRNG 算法曾经被破坏，IMO 比对完整 AES 进行良好的纯文本攻击更有可能，那么您的情况比使用故意确定性填充的​​情况要糟糕得多。

在任何一种情况下，无论您获得填充，它都比 PKCS#5 填充在计算上更加密集。

顺便说一句，使用例如压缩潜在重复数据是相当标准的。在加密之前放气；这减少了数据中的冗余，这会使某些攻击更难以执行。

最后一个建议:使用仅用户名和密码不同的机制来派生 key 是非常危险的。如果要使用它，请确保使用没有已知缺陷的哈希算法(不是 SHA-1，不是 MD-5)。参见 this slashdot story

希望这可以帮助。