沙-1需要utf-8和字节的重新排序。

Question

今天，我在JavaScript中实现了SHA-1。在这样做时，我无意中发现了RFC-3174中没有提到的两个需求。

1. 文本应该是utf-8编码/一个字符应该是8位长。这是有意义的，因为相同的文本应该总是返回相同的散列，但是我在RFC中找不到任何关于它的信息。有什么地方可以记录在案吗？
2. 由于某种原因，每个32位字的字节需要反转，所以第一个字节排在最后。例如，如果我们有32位的块(从左到右阅读)。00110101 00110011 01100110 00001111

在处理字节之前，应按如下方式排列：

    00001111 01100110 00110011 00110101

我也在RFC里找不到任何关于这件事的东西。这是在哪里定义的，是否有理由需要这样做？

Answer 1

文本应该是utf-8编码/一个字符应该是8位长。这是有意义的，因为相同的文本应该总是返回相同的散列，但是我在RFC中找不到任何关于它的信息。有什么地方可以记录在案吗？

这不是SHA-1的要求，而是对您遇到此实现的上下文的某种要求。

沙-1并不假定消息中的字节；它们可能是任何编码、图像数据、随机字节等的文本。然而，一个真正的SHA-1用户谁是哈希文本将关心这一点。假设两个应用程序具有相同的文本字符串，但一个应用程序内部使用UTF-8，另一个应用程序使用UTF-16。如果每个字节只是散列自己的原始内存字节，即使它们的字符串在文本上是相同的，它们也会得到不同的结果。

由于某种原因，每个32位字的字节需要反转，所以第一个字节排在最后。例如，如果我们有32位的块(从左到右阅读)。

这是一个痴呆症转换，所以您应该熟悉这个概念。这实际上是SHA-1的一项要求.FIPS 180-4说(第7页)：

在整个规范中，在表示32位和64位单词时都使用“大端”约定，因此在每个单词中，最重要的位存储在最左边的位位置。

链接的RFC是这样说的(我认为这更让人困惑)：

整数中最不重要的四位由单词表示的最右十六进制数字表示。示例:整数291 = 2^8+2^5+2^1+2^0 = 256+32+2+1由十六进制单词00000123表示。

是否需要执行所描述的步骤取决于上下文。例如，一些CPU本身就是大端字节，不需要这个步骤，对于SHA-1所执行的32位操作，字节的顺序已经是正确的。另一些则是本土化的，需要转换。它还可以依赖于您正在使用的某些网络协议或库的详细信息。