假设我想使用一个安全散列算法，比如 bcrypt，并且我想使用一个年轻的 bcrypt 实现，例如称为libfancybcrypt，而不是一个成熟的实现。
当然，我可以简单地生成几千或几百万个随机字符串，用旧的、完善的库对它们libfancybcrypt 进行哈希处理，最后比较哈希值。所以假设，我已经这样做了，并且有问题的新库对所有随机输入产生了与完善的库相同的结果。
我的问题有两个部分：
假设库作者是可信的。鉴于我上面的随机输入测试：作者不小心引入了一个错误，即存在计算错误哈希的输入的可能性有多大？
假设库作者不可信。鉴于我上面的随机输入测试：作者故意引入某种后门的可能性有多大？
相关但仍然不同：
假设库作者是可信的。鉴于我上面的随机输入测试：作者不小心引入了一个错误，即存在计算错误哈希的输入的可能性有多大？
被信任并不意味着软件的作者是一个能胜任的程序员，知道所有可能的陷阱。这意味着如果您只依赖信任，您将无法知道引入错误的可能性。而且由于此类错误可能仅在竞争条件或某些整数溢出等极少数情况下发生，因此无法保证您会在随机测试用例中触发该错误。
假设库作者不可信。鉴于我上面的随机输入测试：作者故意引入某种后门的可能性有多大？
如果仅通过特定输入激活后门，则如果不彻底检查代码，您将永远无法发现。甚至代码检查也可能无济于事，请参阅Underhanded C Contest 中的示例。这意味着可以引入这样的隐形后门。但同样，您不能仅根据作者不受信任的信息给出具体的可能性。
测试后我可以信任安全哈希实现吗...
根据之前的观察，这个问题不能肯定地回答。除此之外，它在很大程度上取决于您使用该库的目的：如果只是为了获取一些校验和以检测意外损坏的数据，您的测试可能就足够了。If 用于软件故障可能导致死亡、绝密泄露或恶意软件感染关键基础设施的目的，这样的测试可能还不够，尤其是在您不信任作者的情况下。
只要生成的哈希值等于受信任的哈希值，就可以信任生成的哈希值。这立即导致以下问题：
可能存在仅在特定情况下发生的实现错误，例如\0字符处理不正确。如果您使用足够的随机输入进行测试，并且哈希值始终相等，那么这不太可能。计划一个特定的密码导致不正确的哈希不会帮助攻击者。
密码散列特有的另一个问题是盐的生成，它可以使用不安全的随机源来完成，这可以使破解更容易。这可以相对容易地由您自己进行审查。
独立于生成的哈希是否正确，代码可以为所欲为，这在邪恶作者的场景中主要是一个问题，但也存在粗心实现的问题。
有很容易检测到的攻击，例如哈希算法当然不应该进行 IO 操作或访问互联网。
更难检测的是可以被利用的代码，也许某个输入会故意引发缓冲区溢出。因此，虽然生成的哈希实际上是安全的，但攻击者可能会滥用您的进程来攻击服务器。不过，这与散列无关，它适用于所有 3rd 方库。
另一个容易监督的副作用是，如果代码从/dev/random而不是读取/dev/urandom，它可能会耗尽随机源并在过度使用时阻塞服务器。
➽ 我自己更喜欢使用提供安全算法的不受信任的库，而不是使用来自受信任库的不合适的算法。当然这取决于你的服务的重要性，而且自己检查源总是一件好事（哈希算法没有这么多代码）。