在我的一个项目中，我选择 bcrypt 或 PBKDF2 作为 KDF 的密码。我读过 bcrypt 通常更先进，而 scrypt 更好。但是我使用的是 .NET 平台，虽然 nuget 上有各种实现，但微软无法提供 bcrypt/scrypt。最后我决定使用 PBKDF2，因为它是 MS 的默认实现，希望由一些安全专家审查。
但问题是：在这种情况下，最好的行动方案是什么？是否可以从 nuget 中挑选出具有足够下载量的顶级库并相信它已经足够好，因为很多人都在使用它？那我怎么知道它是否足够好。或者如果可以的话，最好使用平台上的东西？我绝对不想自己实现这样的事情。
我们可以在多大程度上信任加密（安全）库的开源实现？
比闭源实现要好得多。
当涉及到真正重要的安全性时，您必须遵循“信任但验证”的原则。相信流行的开源实现更有可能让它正确，并且有足够的眼球来发现错误，但如果它对你真的很重要，请自己验证/审核代码。
使用开源实现，如果它对您来说真的很重要，您实际上可以自己验证它。使用闭源实现，您只有供应商的话。
如果有的话，对开源安全库的不信任是一件好事。它使一些人在使用之前就开始对其进行审核，而不是仅仅因为它们很受欢迎而盲目地信任实现。
你有三个权衡：PBKDF 与另一种算法，开源与封闭，以及测试向量的可用性。
SCrypt 或 BCrypt 可能比 PBKDF2 更安全。另一方面，如果代码中的实现失败（就像Ashley Madison发生 的那样），那么您获得的安全性就会大大降低。
就代码受到审查的程度而言，此类故障可能会引起注意，这就是开源权衡发生的地方。理论上，任何人都可以查看代码。在实践中，你不得不问有多少专家看过。正如 OpenSSL 缺陷所证明的那样，志愿加密分析师的供应非常少。使用 MS PBKDF 代码，您可以期待除编码员之外的其他人进行 QA，并且加密代码在安全开发生命周期下得到相对更多的关注。如果没有其他安全测试指标，100 人使用的 .NET 块对其进行的分析可能比 Microsoft 组件少。
最后，如果有记忆，PBKDF 有测试向量，而其他没有，这使得测试 PBKDF 的正确实现比测试 scrypt 或 bcrypt 的实现更容易。
我应该提一下，几年前我跟踪了免费的加密库，后来在微软的安全开发生命周期团队工作，但不再这样做了。我认为你的问题没有一个简单的答案。
永远不要自己编写加密或散列库，而是使用已经存在的库。那些已经存在的是由经常专门从事它的人制作的。
除此之外。最好使用的应该首先是开源的。通过开源，更多的安全专家/人员有机会发现错误或错误，从而解决更多问题。从逻辑上讲，使用最多的通常也是评论最多的。更高的机会更多的问题已经解决。
您无法真正检查自己是否安全。在这样的算法中发现错误是很困难的。快速示例。一位安全专家可能不会找到所有这些，所以也不要相信闭源代码，因为他们的代码没有像开源代码那样吸引那么多眼球。