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

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

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

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

以下是一些例子，向您展示我来自哪里：

byte[] myPassinBytes = Encoding.ASCII.GetBytes("some password");

or

string password = "P@%5w0r]>";
byte[] saltArray = Encoding.ASCII.GetBytes("this is my salt");
Rfc2898DeriveBytes rfcKey = new Rfc2898DeriveBytes(password, saltArray);

“rfcKey”对象现在可用于设置 .Key 或 .IV 属性 关于对称加密算法类。

ie.

RijndaelManaged rj = new RijndaelManaged ();
rj.Key = rfcKey.Getbytes(rj.KeySize / 8); 
rj.IV = rfcKey.Getbytes(rj.Blocksize / 8);

“rj”应该准备好了！

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

我尝试在 VS2008 中这样做，直接的答案是否定的。但是，对于为什么使用 RFC 类而不是我上面提到的其他替代方案，你们有更好的答案吗？

你真的真的不想直接使用用户密码作为加密密钥，尤其与 AES。

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

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

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

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

这也意味着最终输出密钥是均匀分布的。例如，如果您使用密码，则密钥的 128 位中通常有 16 位为 0（高 ASCII 位）。即使忽略密码猜测，这一点立即使密钥搜索比应有的容易 65536 倍。

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