为什么像 sha1 这样的哈希函数最多只能使用 16 个不同的字符(十六进制)?
抱歉我有这种好奇心。
sha1 使用 [a-f0-9]
字符作为其哈希函数。我可以知道为什么它不使用所有可能的字符 [a-z0-9]
通过使用所有可用的字符它可以大大增加可能的不同散列的数量,从而降低可能发生冲突的概率。
如果您认为这不是一个真正的问题,请发表评论,我会立即删除此问题。
===
正如答案中所述,sha1 NOT
仅使用 16 个字符
。正确的事实是:sha1 是 160 位二进制数据(引用)。我添加这个是为了防止混淆。
Sorry for this curiosity that I have.
sha1 use [a-f0-9]
chars for its hashing function. May I know why it doens't use all the chars possible [a-z0-9]
by using all chars availabe it could grealty increase the number of possibile different hash, thus lowering the probabilty of possibile collision.
If you don't think this is a real question, just leave a comment I will instantly delete this question.
===
As stated in the answer, sha1 does NOT
uses only 16 chars
. The correct fact is: sha1 is 160 bits of binary data (cit.). I have added this to prevent confusion.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
这是错误的推理。 sha1使用40*4=160位。
将其格式化为 40 个十六进制数字只是为了方便(因此也是惯例)。
如果您认为自己处于 160 位可能发生冲突的问题域中,则可以使用具有更大哈希大小的不同加密哈希
This is false reasoning. sha1 uses 40*4=160 bits.
It just happens to be convenient (and therefore, the convention) to format that as 40 hex digits.
You can use different cryptographic hashes with a larger hash size, if you feel you are in a problem domain where collisions start to be likely in 160 bits
使用十六进制只是为了更容易显示。 SHA1 使用 160 位。通过十六进制编码,它允许摘要以字符串形式轻松显示和传输。就这样。
Using hex just allows for easier display. SHA1 uses 160 bits. By hex encoding it, it allows the digest to be easily displayed and transported as a string. That's all.
哈希算法的输出是位。用十六进制表示它们只是一种表示。它确实受益于长度为 0 mod 16 的结果,因此以 17 为基数表示会很不方便。
The output of the hash algorithm is bits. Representing them in hex is just a representation. It does benefit from a result being of length 0 mod 16, so representation in base 17 would be inconvenient.
sha-1 生成一个 160 位哈希值,即 20 个字节,其中有 1461501637330902918203684832716283019655932542976 个可能的值。因为这就是哈希算法的定义方式。
然而,将哈希值编码为可读文本通常很有用,一种方便的方法是将这 20 个字节简单地编码为十六进制(这将占用 40 个字节)。十六进制字符是[a-f0-9]。
sha-1 produces a 160 bit hash, that's 20 bytes, which has 1461501637330902918203684832716283019655932542976 possible values. Because that's how the hash algorithm is defined.
However, it's often useful encode that hash as readable text, and a convenient way is to simply encode those 20 bytes as hex(which will take up 40 bytes). And hex characters are [a-f0-9].
您将表示与内容混淆了。
sha1 是 160 位二进制数据。您可以轻松地用以下方式表示它:
十六进制没有什么神奇之处。这是一种非常常见的机制,用于显示很容易沿着 4 位边界打破的内容。
base 62
输出是用这一点 ruby 生成的:它使用 从一种碱基转换为另一种碱基,并将
0-9
视为 0-9,az
视为 10-35,AZ为36-61。它可以通过包含例如
!@#$%^&*()-_=+\|[]{},.<>/?;:'"~` 进行简单扩展以支持更多数字
如果需要的话(或者任何大量 Unicode 代码点。 )@yes123 特别询问了哈希的 ascii 表示,因此这是将 160 位哈希直接解释为 ascii 的结果:
它看起来不太像,因为:
这种基数转换实际上也很有用;Base64 编码方法使用 64 (而不是我的 62)个字符一次代表 6 位;它还需要两个字符作为“数字”和一个字符作为填充。 UUEncoding 选择了一组不同的“数字”。并且一位堆叠者遇到了一个问题,通过将输入数字的基数更改为输出数字可以轻松解决。
You're confusing representation with content.
sha1 is 160 bits of binary data. You can just as easily represent it with:
There's nothing magical about hexidecimal. It's just very common mechanism for showing content that breaks easily along 4-bit boundaries.
The
base 62
output is generated with this little bit of ruby:It uses the standard idiom for converting from one base to another and treats
0-9
as 0-9,a-z
as 10-35,A-Z
as 36-61. It could be trivially extended to support more digits by including e.g.!@#$%^&*()-_=+\|[]{},.<>/?;:'"~`
if one so desired. (Or any of the vast array of Unicode codepoints.)@yes123 asked about the ascii representation of the hash specifically, so here is the result of interpreting the 160-bit hash directly as ascii:
It doesn't look like much because:
This base conversion can be practically useful, too; the Base64 encoding method uses 64 (instead of my 62) characters to represent 6 bits at a time; it needs two more characters for 'digits' and a character for padding. UUEncoding chose a different set of 'digits'. And a fellow stacker had a problem that was easily solved by changing the base of input numbers to output numbers.