提问人：Bojan 提问时间：9/14/2023 最后编辑：Bojan 更新时间：9/14/2023 访问量：47
在 .NET Standard 2.0 上坚持使用 SHA1
Stuck with SHA1 on .NET Standard 2.0
问：
我正在从 .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 Standard 项目提供结果。
我错过了什么吗？有什么想法吗？
答：
1赞
Maarten Bodewes
9/14/2023
#1
SHA-1 确实容易受到攻击。然而，在防撞性方面，它主要/唯一被破坏。原则上，可以使 PBKDF2 成为例外，因为它不依赖于抗碰撞特性。如果您已经拥有使用不同哈希的 PBKDF2 哈希或派生密钥，这将有问题，因为它们不兼容。由于 PBKDF2 的设计方式（糟糕），您最好还使用 SHA-1 将输出限制为 160 位。
另一种选择是使用替代实现，该实现确实为 PBKDF2 提供哈希选择。Mono 框架可能有一个很好的实现，它有一个与你正在使用的接口相同的接口，尽管这取决于框架需要将多少类与它们的实现（依赖项）一起拖入。缺点是其实现的命名空间相同，并且缺少更新。请注意，PBKFD2 的软件实现速度可能明显变慢，这可能会给可能的对手带来优势。Rfc2898DeriveBytes
最后，这可能是一个摆脱 PBKDF2 的机会，转而使用更新/更好的算法，例如 Argon2 的安全版本。这还没有获得NIST的批准，但PBKDF2已经不再是同类产品中最好的了。但是，当您升级到新框架时，这是一个冒险的举动。
评论