算术运算的 160 位散列的最高有效字节是什么？答案

【问题标题】：What is the most significant byte of 160 bit hash for arithmetic operations?算术运算的 160 位散列的最高有效字节是什么？
【发布时间】：2015-05-18 17:42:05
【问题描述】：

谁能帮我理解 160 位 (SHA-1) 哈希的最高有效字节是什么？

我有一个 C# 代码，它调用密码库从数据流中计算哈希码。结果我得到一个 20 字节的 C# 数组。然后我从另一个数据流中计算另一个哈希码，然后我需要将哈希码按升序排列。

现在，我正在尝试了解如何正确比较它们。显然我需要从另一个中减去一个，然后检查结果是负数、正数还是零。从技术上讲，我有 2 个 20 字节的数组，如果我们从内存的角度来看，它的开头是最低有效字节（较低的内存地址），最后是最高有效的字节（较高的内存地址）。另一方面，从人类阅读的角度来看，最重要的字节在开头，最不重要的字节在结尾，如果我没记错的话，这个顺序用于比较 GUID。当然，如果我们使用一种或另一种方法，它会给我们不同的顺序。哪种方法被认为是比较哈希码的正确或常规方法？这在我们的案例中尤其重要，因为我们正在考虑实现一个应该与现有哈希表兼容的分布式哈希表。

【问题讨论】：

标签： c# .net sha1 dht endianness

【解决方案1】：

您应该将初始哈希视为字节，而不是数字。如果您尝试对它们进行排序以进行索引查找，请使用最容易实现的排序 - 实际上，这里没有通用的“正确”或“常规”。

如果你有一些特定哈希表你想“兼容”（甚至不确定这意味着什么）你应该看看排序哈希表的方法是什么，假设它是甚至相关。如果您需要兼容多个表，您可能会发现需要对不同的表使用不同的排序。

鉴于 cmets，您正在尝试使用 Kademlia，它基于 this document 将哈希视为大端数字：

Kademlia 遵循 Pastry 将键（包括节点 ID）解释为 bigendian 数字。这意味着表示键的字节数组中的低位字节是最重要的字节，因此如果两个键靠得很近，那么距离数组中的低位字节将为零。

这只是对字节的任意解释 - 只要每个人都使用相同的解释，它就可以工作......但如果每个人都决定将它们解释为小端数字，它也可以工作。

【讨论】：

您应该将哈希视为字节，而不是数字。 - 在 DHT 的上下文中不一定正确，因为 DHT 使用距离度量，允许进行一些算术运算要在 ID 上执行（不等式、差异）。所以从某种意义上说，它们是数字。至于“常规”，它们是网络协议，因此网络字节顺序将是一个合理的猜测，但仍然只是一个猜测。所以查阅协议规范当然是必要的。
@the8472：我想说这是为了某种任意排序而对字节进行数字解释 on - 但它们在任何其他方面都不是有意义的数字。这不像保证增加源数据中的一个字节来增加解释数。只要各方以相同的方式解释字节，您就会得到一致的顺序、距离等。
@JonSkeet，DHT 密钥实际上不必是 hashes。这就是通常用于获取随机分布的密钥的方法。协议可以轻松地执行诸如“获取密钥 X，将其增加 1 并将辅助数据存储在该派生密钥下”或其他数值操作之类的事情。 [在 kademlia 中] 路由表按 ID 的自然数字排序排序，而查找按 XOR 度量排序。这些可能是更精细的细节，但我不会说它毫无意义。
@JonSkeet，澄清语义：DHT 是在路由协议之上实现的哈希表。键哈希映射到路由协议的键空间 ID，这些 ID 更像数字。当通过覆盖网络提供其他 RPC 服务而不是简单的键值存储时，这变得相关。人们只是倾向于将其全部归为“DHT”，而不区分各个层。
@JonSkeet，在为加密使用节点 ID 而设计的 DHT 中可以直接使用 ECC 公钥（256 位而不是 160 以实现合理的安全性）来标识自己，这些数字是自然。我的观点是，散列不是路由协议本身的一部分，只是路由协议之上的东西通常但不专门使用的东西。但是，是的，你的答案很清楚，这些主要是技术问题。

【解决方案2】：

您可以使用 SequenceEqual 来比较 Byte 数组，查看以下链接了解详细信息：

How to compare two arrays of bytes

Comparing two byte arrays in .NET

【讨论】：

检查是否相等很容易。就我而言，我需要知道一个哈希码是否大于另一个或小于另一个或等于它。这是哈希的字节顺序进入游戏的地方。