为什么我需要使用 Rfc2898DeriveBytes 类（在 .NET 中）而不是直接使用密码作为密钥或 IV？答案

【问题标题】：Why do I need to use the Rfc2898DeriveBytes class (in .NET) instead of directly using the password as a key or IV?为什么我需要使用 Rfc2898DeriveBytes 类（在 .NET 中）而不是直接使用密码作为密钥或 IV？
【发布时间】：2011-02-09 04:39:59
【问题描述】：

使用 Rfc2898DeriveBytes 和只使用 Encoding.ASCII.GetBytes(string object); 有什么区别？

我在这两种方法上都取得了相对的成功，前者是一种更冗长的方法，而后者则简单明了。两者似乎都允许你最终做同样的事情，但我很难看出使用前者而不是后者的意义。

我能掌握的基本概念是可以将字符串密码转换成用于例如对称加密类AesManaged的字节数组。通过 RFC 类，但您可以在创建 rfc 对象时使用盐值和密码。我认为它更安全，但充其量仍然是一个没有受过教育的猜测！此外，它还允许您返回一定大小的字节数组，以及类似的东西。

这里有几个例子告诉你我来自哪里：

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' 应该准备好了！

令人困惑的部分......所以我可以不只使用我的“rfcKey”对象吗？ 'myPassInBytes' 数组来帮助设置我的 'rj' 对象？

我曾尝试在 VS2008 中执行此操作，但立即回答是否定的。但是对于为什么使用 RFC 类而不是我上面提到的其他替代方案，你们有更好的回答吗？

【问题讨论】：

这道题是关于复习和备考的！

标签： c# cryptography rfc2898

【解决方案1】：

您真的，真的不想将用户密码直接用作加密密钥，尤其是与 AES。

Rfc2898DeriveBytes 是 PBKDF2 的实现。它的作用是反复对用户密码和盐进行哈希处理。这有很多好处：

首先，您可以使用任意大小的密码 - AES 仅支持特定的密钥大小。

其次，添加盐意味着您可以使用相同的密码生成多个不同的密钥（假设盐不是常数，就像在您的示例中那样）。这对于密钥分离很重要；在不同的上下文中重复使用密钥是密码系统被破坏的最常见方式之一。

多次迭代（默认为 1000 次）减缓密码猜测攻击。考虑有人试图猜测您的 AES 密钥。如果您只是使用密码，这将很简单 - 只需尝试每个可能的密码作为密钥。另一方面，对于 PBKDF2，攻击者首先必须为 each 密码猜测执行 1000 次哈希迭代。因此，虽然它只会稍微减慢用户的速度，但它对攻击者的影响却不成比例。（事实上，使用更高的迭代次数是很常见的；通常建议使用 10000）。

这也意味着最终的输出密钥是均匀分布的。例如，如果您使用密码，通常 128 位密钥中的 16 位将为 0（高 ASCII 位）。就在那里，即使忽略密码猜测，keysearch 也会比它应该的要容易 65536 倍。

最后，AES 具有与相关密钥攻击相关的特定漏洞。当攻击者知道使用多个密钥加密的某些数据并且它们之间存在某种已知（或猜测）关系时，相关密钥攻击是可能的。例如，如果您使用“我的 AES 密钥糟透了”（对于 AES-128 为 16 字节）和“MY AES KEY SUCKS”的密码密钥加密数据，则可能会发生相关的密钥攻击。目前最知名的攻击实际上不允许以这种方式破坏完整的 AES，但随着时间的推移，它们已经逐渐变得更好 - 就在上周发布了一种新的攻击，它使用 AES-256 破坏了 13 轮（共 14 轮）相关的密钥攻击。依靠这种攻击不会随着时间的推移变得更好是非常不明智的。

【讨论】：