使用输入密码但不加盐破解 Rfc2898DeriveBytes 密钥答案

【问题标题】：Breaking Rfc2898DeriveBytes key with input password but without salt使用输入密码但不加盐破解 Rfc2898DeriveBytes 密钥
【发布时间】：2014-07-15 14:36:31
【问题描述】：

我正在使用 C# RijndaelManaged 类进行 AES 加密。密钥和 IV 是使用 Rfc2898DeriveBytes 类从输入密码和盐生成的。我的问题是，如果有人获得了输入密码而不是盐，那么破解加密有多难？

【问题讨论】：

盐通常不被视为秘密信息，通常它与加密 blob 存储在表的同一行中，或者作为加密文件标题的一部分以明文形式存储。我不知道在RFC-2898 上是否针对您所描述的情况进行了适当的密码分析，因为它并非设计为以这种方式使用。另外，您为什么要生成 IV？让 Rijndel 类生成 IV 并将其与 salt 一起存储在 header 信息中（IV 也不被视为秘密，仅视为密钥）
也只是因为您使用的是 Rijndael does not mean you are using AES，如果您将此数据发送到另一个您未编写解密的程序，并且它期待真正的 AES，如果您使用错误，您可能会遇到问题块大小。此外，如果您使用的是较新版本的 .NET，您可能会从 AesCryptoServiceProvider 中获得更好的性能
@ScottChamberlain 有时会使用这种方案。只要还包含随机盐，它就被认为是相当安全的。 IV 最好是随机的，但如果每次加密都使用新的盐，那么 IV 甚至可能设置为全零，因为每次加密都会更改派生密钥。

标签： .net aes rijndael rijndaelmanaged rfc2898

【解决方案1】：

检索密钥和 IV 几乎是不可能的。实际上，有时除了公共随机盐之外，还使用存储在源代码中的静态秘密盐。这样，攻击者需要获取源代码或运行时代码以及带有盐和密码哈希的数据库。

这种方案确实需要足够大的（秘密）盐，比如 128 字节。最好使用连接来创建组合的公共和秘密盐。

当然，否则总是有可能弄乱加密，例如容易受到填充预言机攻击，除了加密之外忘记身份验证标签（HMAC）等等等等。

【讨论】：