用AES加密填充随机数据是否有好处？

Question

使用AES加密时，必须将明文填充为密码块大小。大多数库和标准都使用填充，其中填充字节可以根据未填充的明文长度来确定。尽可能使用随机填充字节有好处吗？

我正在实现一种用于存储敏感的按用户和按会话数据的方案。数据通常是JSON编码的键值对，并且可能很短且重复。我正在寻求PKCS＃5的指导，但我计划将AES用于加密算法，而不是DES3。我正在计划为每个数据项随机分配IV，并根据需要由用户ID和密码或会话ID确定一个密钥。

让我惊讶的是纯文本的PKCS＃5填充方案。垫密文到8字节的数据块，1到8个字节被添加在末尾，用该填充字节内容反映的填充字节的数量（即01，0202，030303，可达0808080808080808）。我自己的填充方案是在纯文本的开头使用随机字节，而纯文本的最后一个字符将是添加的填充字节数。

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

一个缺点是相同的未填充明文，IV和密钥将导致不同的密文，从而使单元测试变得困难（但并非不可能-我可以使用伪随机填充生成器进行测试，而使用具有加密强度的生成器进行生产）。

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

由于像PKCS＃5这样的备受赞誉的标准决定使用确定性填充，所以我想知道是否还有其他东西我错过了，或者我认为收益太高了。

Answer 1

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

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

在另一个极端，当您从 PRNG 获取随机字节时，如果您使用相同的随机源来生成密钥，则可能会遇到问题。如果您依次向多个收件人发送加密数据，则您已向前一个收件人提供了有关 PRNG 状态的一大堆信息，这些信息将用于为您的下一个通信会话选择密钥。如果您的 PRNG 算法被破坏（在我看来，这比对完整 AES 进行良好的明文攻击更有可能），那么您的情况比使用故意确定性填充要糟糕得多。

无论哪种情况，无论您如何获得填充，它都比 PKCS#5 填充计算量更大。

顺便说一句，在加密之前使用 deflate 等方法压缩可能重复的数据是相当标准的。这减少了数据的冗余，从而使某些攻击更难以执行。

最后一个建议：使用仅用户名和密码变化的机制派生密钥是非常危险的。如果您打算使用它，请确保您使用的哈希算法没有已知缺陷（不是 SHA-1，不是 MD-5）。参见这个斜线故事

希望这可以帮助。