为什么我需要使用Rfc2898DeriveBytes类(在.NET中)，而不是直接使用密码作为密钥或IV？
使用Rfc2898DeriveBytes和只使用Encoding.ASCII.GetBytes(string object);有什么区别
我使用这两种方法都取得了相对的成功，前者是一种更冗长的方法，后者简单而切中要害。两者似乎最终都允许你做同样的事情，但我正在努力理解使用前者而不是后者的意义。
通过RFC类，但您可以在创建rfc对象时使用Salt值和密码。我认为它更安全，但这充其量也是一个未经训练的猜测！它还允许你返回一定大小的字节数组，嗯，类似的东西。
这里有几个例子来向你展示我的来历：
byte[] myPassinBytes = Encoding.ASCII.GetBytes("some password");或
string password = "P@%5w0r]>";
byte[] saltArray = Encoding.ASCII.GetBytes("this is my salt");
Rfc2898DeriveBytes rfcKey = new Rfc2898DeriveBytes(password, saltArray);“rfcKey”对象现在可用于设置对称加密算法类的.Key或.IV属性。
即。
RijndaelManaged rj = new RijndaelManaged ();
rj.Key = rfcKey.Getbytes(rj.KeySize / 8);
rj.IV = rfcKey.Getbytes(rj.Blocksize / 8);“‘rj”应该已经准备好了！
令人困惑的是..。
我在VS2008中尝试过这样做，立即得到的答案是否定的。但是，对于为什么使用RFC类而不是我上面提到的其他选择，你们有更好的答案吗？
回答 1
Stack Overflow用户
发布于 2010-05-08 02:16:31
您真的、真的不想将用户密码直接用作加密密钥，特别是在使用AES时。
Rfc2898DeriveBytes是PBKDF2的一种实现。它所做的就是重复地散列用户密码和盐。这有多个好处：
首先，你可以使用任意大小的密码- AES只支持特定的密钥大小。
其次，盐的添加意味着您可以使用相同的密码短语来生成多个不同的密钥(假设盐不是常量，就像在您的示例中一样)。这对于密钥分离很重要；在不同的上下文中重用密钥是破坏密码系统的最常见方式之一。
多次迭代(默认情况下为1000次)会降低密码猜测攻击的速度。考虑一下正在尝试猜测您的AES密钥的人。如果您只是使用密码，这将是简单的-只需尝试每个可能的密码作为密钥。另一方面，使用PBKDF2，攻击者首先必须对每个密码猜测执行1000次哈希迭代。因此，虽然它只略微降低了用户的速度，但对攻击者的影响却不成比例。(事实上，使用更高的迭代次数是很常见的；通常推荐10000次)。
这也意味着最终的输出密钥是均匀分布的。例如，如果您使用密码，通常128位密钥中的16位将是0(高位ASCII位)。这会立即使关键字搜索变得比正常情况下容易65536倍，即使忽略了密码猜测。
最后，AES具有与相关密钥攻击相关的特定漏洞。当攻击者知道一些用几个密钥加密的数据，并且它们之间存在某种已知(或猜测)关系时，就可能发生相关的密钥攻击。例如，如果您使用"My AES key SUCKS“的密码密钥(对于AES -128为16字节)和"MY AES KEY sucks”对数据进行加密，则可能会发生相关的密钥攻击。目前最著名的攻击实际上不允许以这种方式破解完整的AES，但随着时间的推移，它们已经逐渐变得更好-就在上周发布了一个新的攻击，使用相关的密钥攻击破解了13轮(总共14轮) AES-256。依赖这样的攻击而不是随着时间的推移而变得更好是非常不明智的。
https://stackoverflow.com/questions/2659214
复制相似问题