为什么BCrypt.net GenerateSalt(31)会立即返回？

Question

在阅读了BCrypt.net之后，我偶然发现了杰夫·阿特伍德关于储存密码的帖子，这使我看到了Thomas关于使用BCrypt存储密码的建议。这让我终于找到了这个C#实现的BCrypt

在上面对最后一个链接的评论中，有人问：“为什么GenerateSalt(30)要永远保持下去，而GenerateSalt(31)似乎根本不需要时间？”

我运行了BCrypt.HashPassword(密码，BCrypt.GenerateSalt(31))，并在0毫秒内得到了结果。

我已经运行BCrypt.HashPassword(“密码”，BCrypt.GenerateSalt(30))超过5分钟了，但仍然没有结果。

我意识到我们可能不需要一个随机生成的30个字符的salt来创建密码散列(或不可逆加密在BCrypt案中的应用)。编辑我应该读一些代码，logRounds与盐的长度没有任何关系。谢谢奥尼尔。

那么，为什么GenerateSalt(31)几乎立即返回一个值(当它所需的时间大约是GenerateSalt(30)的两倍时)？

更新

以下是解决办法：

private byte[] CryptRaw(byte[] password, byte[] salt, int logRounds) {
    // ... snip ...
    uint rounds = 1U << logRounds;
    // ... snip
}

Answer 1

我怀疑窃听器就在这里

private byte[] CryptRaw(byte[] password, byte[] salt, int logRounds) {
    // ... snip ...
    int rounds = 1 << logRounds;
    // ... snip
}

当为logRounds指定31时，它会计算为2^32，这不能适应int并溢出，因此哈希实际上是在.呃，零关。作者应该使用uint代替。修起来容易！

还想对此发表评论：

我意识到我们可能不需要随机生成30个字符的盐来创建密码哈希.

请注意，logRounds参数并不是指salt中的字符/字节数，它始终是16个字符/字节。它指的是散列计算所需的传递数的对数基数；换句话说，它是一种使用摩尔定律进行bcrypt缩放的方法，如果计算机速度快到足以破解现有散列，则计算该函数的成本会增加几个数量级。

Answer 2

如果使用GenerateSalt(31)的散列几乎立即返回，那就是一个bug。您应该向上游报告(对于jBCrypt，我已经报告了)。:-)

默认情况下，日志轮为10，这意味着(如果我没记错的话)，使用1024轮。每次增加日志轮时，轮数就会增加一倍.

30回合的时候，你就可以打1073741824发了。这当然需要很长时间。在31轮日志中，应该会执行2147483648轮，但我怀疑您使用的是溢出的特定实现。:-(