根据我之前是不是打印出切片，在附加切片后计算 sha256 会给出不同的结果

Posted 2023-02-23

【中文标题】根据我之前是不是打印出切片，在附加切片后计算 sha256 会给出不同的结果

【英文标题】：Calculating sha256 gives different results after appending slices depending on if I print out the slice before or not根据我之前是否打印出切片，在附加切片后计算 sha256 会给出不同的结果

【发布时间】：2020-05-08 15:50:45

【问题描述】：

我正在从多个字符串计算 sha256。我以特定方式将它们转换为字节片并将它们全部附加在一起，然后使用内置库计算散列。但是，取决于我是否在计算 sha256 之前打印出切片，我会奇怪地得到不同的结果。在操场上测试时，我无法重现它。

可以在https://play.golang.org/p/z8XKx-p9huG 上查看和运行经过测试的代码，在这两种情况下它实际上给出了相同的结果。

func getHash(input1 string, input2hex string, input3hex string, input4 string) (string, error) 
    input1bytes := []byte(input1)
    firstHalfinput1Bytes := input1bytes[:8]
    secondHalfinput1Bytes := input1bytes[8:16]

    input4Bytes := []byte(input4)

    input3Bytes, err := hex.DecodeString(input3hex)
    if err != nil 
        fmt.Println("err " + err.Error())
    

    input2Bytes, err := hex.DecodeString(input2hex)
    if err != nil 
        fmt.Println("err " + err.Error())
    

    fullHashInputBytes := append(firstHalfinput1Bytes, input2Bytes...)
    // THIS IS THE OPTIONAL PRINT WHICH CHANGES OUTPUT LOCALLY:
    fmt.Println("fullHashInputBytes", fullHashInputBytes)
    fullHashInputBytes = append(fullHashInputBytes, secondHalfinput1Bytes...)
    fullHashInputBytes = append(fullHashInputBytes, input3Bytes...)
    fullHashInputBytes = append(fullHashInputBytes, input4Bytes...)
    sha256 := sha256.Sum256(fullHashInputBytes)
    for i := 0; i < 8; i++ 
        sha256[i+16] ^= sha256[i+24]
    
    hash := hex.EncodeToString(sha256[:24])
    fmt.Println("hash", hash)
    return hash, nil

操场上的日志是

Hello, playground
fullHashInputBytes [84 72 73 83 73 83 78 79 30 0 22 121 57 203 102 148 210 196 34 172 210 8 160 7]
hash 0161d9de8dd815ca9f4e1c7bb8684562542cc24b1026321c
hash 0161d9de8dd815ca9f4e1c7bb8684562542cc24b1026321c

但如果我在本地运行完全相同的代码（只需将其复制粘贴到 main.go 并执行go run main.go 或go build . 和./test）我得到

Hello, playground
fullHashInputBytes [84 72 73 83 73 83 78 79 30 0 22 121 57 203 102 148 210 196 34 172 210 8 160 7]
hash 0161d9de8dd815ca9f4e1c7bb8684562542cc24b1026321c
hash d2de4ffb4e8790b8fd1ceeba726436fd97875a5740c27b47

我使用的是 go 版本 1.13.4，但与 1.10.4 有同样的问题。我在本地机器上和部署到我们的服务器时也遇到了同样的问题。

【问题讨论】：

您的问题有点“忙” - 所以让我问一下，在将数据中继到哈希器时是否使用了任何缓冲（例如 bytes.Buffer）？如果是这样，请确保刷新最终写入以确保您正在散列整个有效负载。

代码和你看到的完全一样，没有缓冲区。我用硬编码的字符串测试它（见操场链接）。但也许我可以删除几乎所有的问题，只需参考游乐场链接以使其更易于消化:)

删除了大部分文字并转而引用链接，希望它不那么忙！

问题应该在问题正文中包含相关代码，而不仅仅是在外部链接中。

【参考方案1】：

这是因为您首先通过附加到firstHalfinput1Bytes 来创建fullHashInputBytes：

fullHashInputBytes := append(firstHalfinput1Bytes, input2Bytes...)

这是input1bytes的一部分：

firstHalfinput1Bytes := input1bytes[:8]

所以第一个追加可能会覆盖input1bytes在索引大于7的内容，这实际上是secondHalfinput1Bytes的内容：

secondHalfinput1Bytes := input1bytes[8:16]

因此，稍后当您还将secondHalfinput1Bytes 附加到fullHashInputBytes 时，您最终可能会附加不同的内容。

这很可能不是你想要的。

如果你这样做“干净”：

var fullHashInputBytes []byte
fullHashInputBytes = append(fullHashInputBytes, firstHalfinput1Bytes...)
fullHashInputBytes = append(fullHashInputBytes, input2Bytes...)
// OPTIONAL print doesn't change anything:
fmt.Println("fullHashInputBytes", fullHashInputBytes)
// ...rest of your appends...

如果您在本地或Go Playground 上运行，输出将是相同的。

为什么会出现异常行为？

你的第一个追加是否覆盖input1bytes取决于是否可以“就地”执行追加，而不必分配新的后备数组，这取决于firstHalfinput1Bytes的容量，它是“继承”自input1bytes:

input1bytes := []byte(input1)
fmt.Println(cap(input1bytes))

（您可以在此处详细了解它：Concatenate two slices in Go）。

conversion[]byte(input) 只保证有input1 的字节，但规范并没有规定结果切片的容量应该有多大。它可能取决于平台/架构。在 Go Playground 上，上述转换结果为 capacity = 16，在我的本地 amd64 架构上，我得到 capacity = 32。

最后一点：[]byte(input) 转换结果切片所使用的容量可能取决于您对结果切片的操作。如果您将其传递给fmt.Println()，编译器可能会决定使用较低容量，因为这表明切片可能会逃逸。同样，编译器做出的决定不在您的掌控之中。

不要依赖这样的东西，不要编写依赖于转换结果切片容量的代码。以“干净”的方式进行：不要附加到firstHalfinput1Bytes，而是附加到新切片。

【讨论】：

感谢您的回答，有道理！我最终制作了具有最终容量的切片并复制了其他切片的内容，但无论如何很高兴知道这一点！有趣的是，我们在另一项服务中具有几乎相同的功能（实际内容略有不同，最后再追加一个，可能对最终容量有影响），我也犯了这个错误，但是总是给出正确的预期校验和¯_(ツ)_/¯

@poppe 不要急于求成，不要依赖语言规范未指定的容量。如果你这样做了，你的代码可能会在下一个版本的 Go 中给出错误的结果。

@izca 如果你指的是另一个犯了同样错误的服务，我们现在正在修复它，所以它也能以正确的方式进行:)

@poppe 是的，我指的是那个。