在 .NET Standard 2.0 上使用 SHA1

Question

我正在从 .NET Framework 升级到 .NET。 问题是我们有一个包含 100 多个项目的大型解决方案。我们的想法是，这可以分阶段进行。我们可以升级到 .NET Standard 2.0（我们可以升级到的最高版本），然后分阶段升级到 .NET（有些可能永远不会升级到 .NET，或者在其他解决方案中分离）。

问题中提到了我遇到的问题：无法为 Rfc2898DeriveBytes 指定 4 个参数（哈希算法名称）。

更具体地说，在我们当前的 .NET Framework 解决方案中，我们使用更高的哈希算法，但 .NET Standard 强制使用 SHA1。请参阅Rfc2898DeriveBytes 类。

NIST 强烈建议不要使用 SHA1。请参阅NIST 淘汰 SHA-1 加密算法。我不会将其称为零日漏洞，因为 NIST 计划在 2030 年 12 月 31 日之前逐步淘汰。

使用第三方库来完成如此重要的事情不是一个选择。

我们对密码实行零知识政策。此外，在 .NET Standard 2.0 中，应用程序无法动态加密和比较使用更高哈希算法生成的哈希值。这使得应用程序无法使用。

一种选择是创建一个新的 .NET 项目，该项目只需向 .NET 标准项目提供结果。

我错过了什么吗？有什么想法吗？

Answer 1

SHA-1 确实容易受到攻击。然而，它主要/仅在抗碰撞方面被破坏。原则上，PBKDF2 可能是一个例外，因为它不依赖于抗碰撞属性。如果您已经拥有使用不同哈希的 PBKDF2 哈希或派生密钥，这将是有问题的，因为它们不兼容。由于 PBKDF2 的设计方式（糟糕），您最好也将 SHA-1 的输出限制为 160 位。

另一种选择是使用替代实现，为 PBKDF2 提供哈希选择。 Mono 框架可能有一个很好的实现，它与您正在使用的接口具有相同的接口，尽管这取决于框架需要将多少类与其

Rfc2898DeriveBytes

实现（依赖项）一起拖入。缺点是它们的实现具有相同的命名空间并且缺少更新。请注意，PBKFD2 的软件实现可能会明显变慢，这可能会给潜在的对手带来优势。

最后，这可能是一个摆脱 PBKDF2 的机会，转而采用更新/更好的算法，例如安全版本的 Argon2。这并未获得 NIST 批准，但 PBKDF2 已经不再是同类中最好的了。不过，当您升级到新框架时，这是一个冒险的举动。