为什么最常见的散列 (SHA1) 密码前缀是“00000”？
Why the most common prefix of hashed (SHA1) passwords is "00000"?
我正在阅读 Troy Hunt 的博客 (https://www.troyhunt.com/ive-just-launched-pwned-passwords-version-2/) 中的 post，关于一个名为 "Pwned Passwords" 的功能，该功能检查您的密码是否在泄露超过 10 亿的数据库中密码。
要在不传递密码的情况下进行此检查，客户端代码对其进行哈希处理并仅传递该哈希值的前五个字符，后端 returns 所有以前缀开头的密码的 sha1 哈希值你通过了。然后，为了检查你的密码的哈希值是否在数据库中，在客户端代码上进行比较。
他还提供了一些关于这些散列密码数据的信息...
- Every hash prefix from 00000 to FFFFF is populated with data (16^5 combinations)
- The average number of hashes returned is 478
- The smallest is 381 (hash prefixes "E0812" and "E613D")
- The largest is 584 (hash prefixes "00000" and "4A4E8")
在评论中，人们想知道这个“00000”的存在是巧合还是数学...
有懂 SHA1 算法的大神能给我们解释一下吗？
这要么是巧合，要么（不太可能）是 artifact/error 在获取或组装结果以供发布时的结果。
并不是说它看起来像一个重要的异常值。所描述的分布（381 分钟，平均 478，最大 584）似乎是样本量的均匀分布。整个语料库的图表可能看起来很随机。
与任何构造合理的哈希算法一样，SHA1 结果中的字符频率应该是随机分布的。 （如果 SHA1 有某种偏差，这将是数学和 cryptography/cryptology 社区的重大新闻！）
好吧，由于密码最初来自数据泄露，我最好的猜测是其中一个被破坏系统中的密码 table 被排序或聚类（未加盐 - 那些人是那种人谁的密码被盗）密码的 SHA1 散列。当系统被攻破时，攻击者从“00000”哈希值开始，只是没有成功...
或者 Troy 使用的列表可能包含 SHA1 彩虹的第一部分 table (https://en.wikipedia.org/wiki/Rainbow_table)...
或者类似的东西。基本思想是密码的 SHA1 散列是密码选择过程的一部分。
有人需要根据 sha1 算法检查我的猜测（并且 troy 可能已经揭穿了它，因为根据他的博客回答，他“在 [纯文本] 密码上达到了顶峰）但是因为密码只是 alpha/numeric 和 ASCII 中描述的有限符号创建哈希将始终以零的第一位开始工作（ascii 是 0-255，但我相信使用的字母数字和符号在 32-98 范围内，所以每 8 个的第一位bits always zero) 虽然它是散列的函数来掩盖这一点，但我怀疑可预测的位定位并不像人们预期的那样容易混淆。虽然它与 4 相关，但 0 是位形式的 00000000 而 4 是 00000100所以两者的前五位都是 0，
还要注意两个最不频繁的散列 headers 都以 E 开头，在二进制中是 11111110，因此它们在构造（1 对 0）和频率（低对高）方面几乎完全相反，这意味着零位的存在可能是算法的副作用（值得怀疑），也可能是算法在按惯例倾斜的有限子集上的函数，换句话说，字母和数字仅占算法的 1/3 - 1/4最有可能
的 ASCII 描述的完整范围
我们当然可以 "tin foil hat" 参加这个会议，但我敢打赌巧合和 ASCII 比草丘上的那个人更应该受到指责
我正在阅读 Troy Hunt 的博客 (https://www.troyhunt.com/ive-just-launched-pwned-passwords-version-2/) 中的 post，关于一个名为 "Pwned Passwords" 的功能，该功能检查您的密码是否在泄露超过 10 亿的数据库中密码。
要在不传递密码的情况下进行此检查，客户端代码对其进行哈希处理并仅传递该哈希值的前五个字符，后端 returns 所有以前缀开头的密码的 sha1 哈希值你通过了。然后，为了检查你的密码的哈希值是否在数据库中，在客户端代码上进行比较。
他还提供了一些关于这些散列密码数据的信息...
- Every hash prefix from 00000 to FFFFF is populated with data (16^5 combinations)
- The average number of hashes returned is 478
- The smallest is 381 (hash prefixes "E0812" and "E613D")
- The largest is 584 (hash prefixes "00000" and "4A4E8")
在评论中，人们想知道这个“00000”的存在是巧合还是数学...
有懂 SHA1 算法的大神能给我们解释一下吗？
这要么是巧合，要么（不太可能）是 artifact/error 在获取或组装结果以供发布时的结果。
并不是说它看起来像一个重要的异常值。所描述的分布（381 分钟，平均 478，最大 584）似乎是样本量的均匀分布。整个语料库的图表可能看起来很随机。
与任何构造合理的哈希算法一样，SHA1 结果中的字符频率应该是随机分布的。 （如果 SHA1 有某种偏差，这将是数学和 cryptography/cryptology 社区的重大新闻！）
好吧，由于密码最初来自数据泄露，我最好的猜测是其中一个被破坏系统中的密码 table 被排序或聚类（未加盐 - 那些人是那种人谁的密码被盗）密码的 SHA1 散列。当系统被攻破时，攻击者从“00000”哈希值开始，只是没有成功...
或者 Troy 使用的列表可能包含 SHA1 彩虹的第一部分 table (https://en.wikipedia.org/wiki/Rainbow_table)...
或者类似的东西。基本思想是密码的 SHA1 散列是密码选择过程的一部分。
有人需要根据 sha1 算法检查我的猜测（并且 troy 可能已经揭穿了它，因为根据他的博客回答，他“在 [纯文本] 密码上达到了顶峰）但是因为密码只是 alpha/numeric 和 ASCII 中描述的有限符号创建哈希将始终以零的第一位开始工作（ascii 是 0-255，但我相信使用的字母数字和符号在 32-98 范围内，所以每 8 个的第一位bits always zero) 虽然它是散列的函数来掩盖这一点，但我怀疑可预测的位定位并不像人们预期的那样容易混淆。虽然它与 4 相关，但 0 是位形式的 00000000 而 4 是 00000100所以两者的前五位都是 0，
还要注意两个最不频繁的散列 headers 都以 E 开头，在二进制中是 11111110，因此它们在构造（1 对 0）和频率（低对高）方面几乎完全相反，这意味着零位的存在可能是算法的副作用（值得怀疑），也可能是算法在按惯例倾斜的有限子集上的函数，换句话说，字母和数字仅占算法的 1/3 - 1/4最有可能
的 ASCII 描述的完整范围我们当然可以 "tin foil hat" 参加这个会议，但我敢打赌巧合和 ASCII 比草丘上的那个人更应该受到指责