2012-07-06 145 views
0

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

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

+1

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

回答

1

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

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

+0

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

+0

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

+0

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