AES（RijndaelManaged）解密额外字符？答案

【问题标题】：AES (RijndaelManaged) Decrypt Extra Characters?AES（RijndaelManaged）解密额外字符？
【发布时间】：2012-07-06 15:25:19
【问题描述】：

所以，我正在使用 RijndaelManaged 类 (.NET 2.0) 对配置文件中的小字符串（大约十几个字符或更少）进行 AES-128 CBC 加密。除了当我解密数据时，填充字节没有被删除之外，我已经让一切正常工作了。我知道我可以选择不进行任何填充，但这是非常不安全的，并且需要添加填充字节，因为这就是 AES 的工作方式（以谨慎的块大小）。现在我使用PaddingMode.ISO10126 让CryptoStream 自动附加加密随机字节。

处理此问题的行业标准方法是什么？在解密时摆脱这些“额外字节”的正确方法是什么？

【问题讨论】：

填充由密码自动添加和删除，只要您正确指定填充模式，并告诉密码实例被解密的块是最终块，对于例如通过CryptoStream.FlushFinalBlock()

标签： vb.net encryption .net-2.0 aes

【解决方案1】：

摆脱填充的最佳方法当然是改用 PKCS#7 填充，并让密码实例摆脱填充，正如 GregS 建议的那样。

如今执行加密的最佳方式是改用 CTR 模式加密，或者最好使用包含身份验证/完整性保护的密码，例如 GCM。请注意，对于小字符串，您需要注意不要通过密文的大小泄露信息（对“是”执行 CTR 模式加密的结果将导致三个字节，“否”将导致 2 个字节）。

【讨论】：

对于 CTR 模式（以及 GCM），nonce 规则是必不可少的。对于这些模式，重用 nonce 真的很糟糕。但是如果使用得当，这些都是 IMO 的绝佳模式。不幸的是，.net 没有为他们提供开箱即用的实现。
@CodeInChaos 在 CBC 模式下重用或使用非随机 IV 也很糟糕。微软在实施新的加密标准方面真的很慢，在这方面对于这么大的公司来说他们的表现相当糟糕。
是的，实际上我自己想通了，解决方案正是您所建议的。首先，我需要按照你说的设置填充模式。然后，当我解密时，解密方法返回一个整数，然后是解密值的长度。我只需要阅读到那个长度，否则我正在阅读垃圾。我还发现不再推荐使用 ISO10126 加密，因为它会引入漏洞。填充文本是否可预测并不重要，因为像 AES 这样的良好算法可以抵抗已知的明文攻击。
@owlstead 为什么重复使用 IV 不好？目前我正在使用相同的 IV 来加密所有的值...
使用ECB不好的原因相同；如果开头的纯文本相同，您将泄漏信息。例如。将“是”一词加密两次。两个密文将是相同的。这只是窃听。