盐长与总哈希长度比

Question

我正在使用KeyDerivation.Pbkdf2生成密码哈希，我想知道一般建议是关于盐长度与Pbkdf2输出的总体哈希长度相比。

在下面的实现中，我使用HMACSHA512，并且假设salt是512位，并且hashBitLength也是512位。

KeyDerivation.Pbkdf2(password, salt, KeyDerivationPrf.HMACSHA512, iterationCount, hashBitLength/8); 

我见过它使用HMACSHA256一个例子，但它的盐设置为128位和整体哈希位长度为256 为什么会采取这种方式？

我读过512位可能是矫枉过正，但在存储方面，它并不关心我（我不知道性能如何受到影响，但我没有测试过）。

盐的长度应与整个生成的散列值相同。 它应该是一半？ 或者它应该超过某个阈值并低于整体长度？

我的直觉告诉我做这件事的方式是正确的（除了可能是512位），因为我怀疑我得到的是最大熵，但我不是密码学家。

有人可以请澄清这一点吗？

Answer 1

它确实不需要那么大，但让我们明白为什么。盐的目的是：

1. 如果两个人有相同的密码，那么'散列'结果不应该是相同的。
2. 预防rainbow table attacks。

第一点可以通过简单地用一个计数器来完成 - 至少，防止重复自己的数据库，但可能无法阻止你的数据库中的密码的哈希被相同的哈希在别人的数据库中使用相同的密码。这使我们想到了第二点。

如果只是简单地使用一个从零开始的计数器，那么可以基于它构造一个彩虹表。盐越大，彩虹桌就越有可能有效。这些表与盐的大小成指数增长，所以你的盐真的不需要那么大才能排除这种攻击。

很难指出一个最小尺寸，但我可以向你保证，128位是绰绰有余。作为一名安全代码审计员，我个人当然不会提出一个小至64位的盐的问题。

有关此主题的安全建议的一个重大问题是没有人分析过它 - 相反，您只是从声称自己是专家的人那里获得盲目推荐。我写了一篇关于password processing的论文。具体见第3节关于我对盐的咆哮。

备注：完全排除彩虹表，不要使用计数器。相反，选择你的盐'足够大'（如上），并以不可预知的方式。