为什么此代码首先将随机盐编码为十六进制数字?
我正在查看一些生成盐的现有代码,该盐用作身份验证哈希的输入。
salt 的长度为 16 字节,首先使用操作系统随机数生成器获取 8 字节的随机数据来生成。
然后,8 字节缓冲区中的每个字节用于将数据放入 16 字节缓冲区的 2 字节中,如下所示:
out[j] = hexTable[data[i] & 0xF];
out[j-1] = hexTable[data[i] >> 4 & 0xF];
其中 out
是 16 字节 salt,data
是初始值。 8 字节缓冲区,j
和 i
显然只是循环增量器,hexTable
只是一个十六进制数字数组,即 0< /代码> 到
F
。
为什么要做这一切?为什么 16 字节 salt 一开始不填充随机数据?为什么要经历这个复杂的过程?
这里所做的是产生盐的标准方法吗?与一开始就生成 16 个随机字节相比,这样做有什么好处和要点?
I'm looking at some existing code that is generating a salt which is used as input into an authentication hash.
The salt is 16 bytes long, and is generated by first using an OS random number generator to get 8 bytes of random data.
Then each byte in the 8 byte buffer is used to place data into 2 bytes of the 16 byte buffer as follows:
out[j] = hexTable[data[i] & 0xF];
out[j-1] = hexTable[data[i] >> 4 & 0xF];
Where out
is the 16 byte salt, data
is the initial 8 byte buffer, j
and i
are just loop incrementers obviously, and hexTable
is just an array of the hex digits i.e. 0
to F
.
Why is all this being done? Why isn't the 16 byte salt just populated with random data to begin with? Why go through this elaborate process?
Is what is being done here a standard way of generating salts? What's the benefit and point of this over just generating 16 random bytes in the first place?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
这只是将 8 个随机字节转换为 16 个十六进制数字。
似乎有人误解了盐的概念,或者你的哈希需要什么输入,并认为它只接受十六进制数字。
也许盐也存储在更容易存储十六进制数字而不是纯字节的地方,并且程序员认为能够按原样重用存储的盐(即不首先将其转换回字节)会很好。
This is simply conversion of your 8 random bytes to 16 hexadecimal digits.
It seems that someone misunderstood the concept of salt, or what input your hash needs, and thought it only accepts hexadecimal digits.
Maybe also the salt is stored somewhere where it is easier to store hexadecimal digits instead of pure bytes, and the programmer thought it would be good to be able to reuse the stored salt as-is (i.e. without converting it back to bytes first).