AES（RijndaelManaged）解密额外的字符？

因此，我使用RijndaelManaged类（.NET 2.0）对配置文件中的小字符串（大约十几个字符或更少）执行AES-128 CBC加密。除了当我解密数据时，我没有删除填充字节。我知道我可以选择不做任何填充，但这是非常不安全的，并且需要添加填充字节，因为这是AES工作原理（以谨慎的块大小）。现在我使用PaddingMode.ISO10126来让CryptoStream自动附加密码随机字节。AES（RijndaelManaged）解密额外的字符？

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

来源

2012-07-06 John

只要您正确指定了填充模式，并且通过密码实例告诉密码实例解密的块是最后一个块，例如通过CryptoStream.FlushFinalBlock（）可以自动添加*和删除填充* – 2012-07-06 22:03:43

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

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

来源

2012-07-06 23:27:06

CTR模式（以及GCM）以及nonce纪律是必不可少的。对于这些模式，重用一个随机数*是非常糟糕的。但是当正确使用时，这些都是IMO的伟大模式。不幸的是.net对他们没有开箱即用的实现。 – CodesInChaos 2012-07-06 23:29:36

@CodeInChaos在CBC模式下重复使用或使用非随机IV也很糟糕。 MicroSoft在实施新的加密标准方面确实很慢，对于这样的大公司来说，它们表现相当差劲。 – 2012-07-06 23:33:13

是的，我实际上已经想出了自己，解决方案就是你的建议。首先，我需要像你说的那样设置填充模式。然后，当我解密时，解密方法返回一个整数，然后解密值的长度。我只需要阅读这个长度，否则我正在阅读垃圾。我还发现ISO10126加密不再被推荐，因为它可能引入漏洞。填充文本是否可预测并不重要，因为像AES这样的好算法可以抵抗已知的明文攻击。 – John 2012-07-09 14:25:21

AES（RijndaelManaged）解密额外的字符？

回答

相关问题