Go 怎样比较敏感摘要而避免短路差异

比较密码摘要、签名标签或其他敏感字节序列时，不要直接用会在首个不同字节处结束的写法。Go 标准库的 crypto/subtle.ConstantTimeCompare 会在长度相同的前提下按内容无关的时间路径比较，并返回整数 1 或 0。长度不同时它会立即返回 0，所以调用方仍然要明确长度边界。

如果两边是已经算好的等长摘要，可以使用 subtle.ConstantTimeCompare；如果场景是 HMAC 校验，优先使用 hmac.Equal，并把摘要计算、长度处理和比较放在同一个小函数里。

官方文档：https://pkg.go.dev/crypto/subtle#ConstantTimeCompare

普通字节比较为什么会留下短路差异

普通的切片比较通常会先判断长度，再从头检查内容，遇到第一个不同位置就可以结束。对于普通业务数据，这种行为没有问题；但当比较结果决定是否接受一个敏感摘要时，不同输入的比较耗时可能携带“前面有多少字节相同”的信息。

常量时间比较也不是“任何条件下耗时完全一样”。它只能把内容差异带来的提前结束压平，长度仍然是一个公开的边界条件。摘要算法、编码方式和调用路径也必须先设计一致。

等长摘要怎样用 ConstantTimeCompare

ConstantTimeCompare 的参数是两个 []byte，返回值是整数。不要把它写成布尔表达式的隐式替代品，直接判断返回值更清楚：

package digestcheck

import "crypto/subtle"

// EqualDigest 只比较已经编码成字节切片的摘要。
// 长度不一致时返回 false，避免把不同摘要格式混在一起比较。
func EqualDigest(expected, actual []byte) bool {
	if len(expected) != len(actual) {
		return false
	}
	// 返回值为 1 表示内容相同，0 表示不同。
	return subtle.ConstantTimeCompare(expected, actual) == 1
}

这里的长度判断主要是调用约束和语义表达：两种摘要格式不同就不应该进入同一个比较分支。真正的内容比较交给 ConstantTimeCompare，它会在等长输入上遍历内容而不因某个字节不同就提前退出。

长度不一致时应该怎样处理

文档明确说明，长度不相等时 ConstantTimeCompare 会立即返回 0。这意味着它适合比较同一种摘要算法、同一种编码格式产生的结果；它不是“把任意两个长度的序列都变成常量时间”的通用函数。

如果摘要来自十六进制字符串，先在协议层决定比较二进制摘要还是比较规范化后的文本，不能一边传 32 字节原始摘要、一边传 64 个字符的十六进制文本。对于固定算法，也可以在进入比较函数前把长度当成格式错误处理。

package digestcheck

import (
	"crypto/sha256"
	"crypto/subtle"
)

// EqualSHA256 比较 SHA-256 的原始 32 字节摘要，不比较十六进制字符串。
func EqualSHA256(expected, data []byte) bool {
	actual := sha256.Sum256(data)
	// [32]byte 转成切片后，长度天然固定为 32。
	return subtle.ConstantTimeCompare(expected, actual[:]) == 1
}

这个函数的调用方仍应传入同一算法产生的摘要。常量时间比较解决的是内容比较的短路差异，不负责确认摘要算法、编码和业务上下文。

HMAC 校验为什么优先用 hmac.Equal

HMAC 场景不只是“比较两个字节切片”：服务端还要用同一密钥和同一消息重新计算 MAC。Go 的 crypto/hmac 已经提供了 Equal，文档直接把它定位为避免时序侧信道的 MAC 比较函数。把它放在校验函数里，可以减少调用方遗漏长度或误选比较函数的机会。

package auth

import (
	"crypto/hmac"
	"crypto/sha256"
)

// ValidMAC 重新计算消息标签，再用 hmac.Equal 做安全比较。
func ValidMAC(message, receivedMAC, key []byte) bool {
	macHash := hmac.New(sha256.New, key)
	// 写入消息后读取完整的 HMAC 标签。
	_, _ = macHash.Write(message)
	expectedMAC := macHash.Sum(nil)
	// hmac.Equal 同时处理 MAC 比较语义与长度不一致情况。
	return hmac.Equal(receivedMAC, expectedMAC)
}

这里忽略 Write 的错误是因为标准库 HMAC 的写入不会返回实际错误；如果换成可能失败的流式输入，应在摘要计算阶段保留并处理真实错误。不要把密钥、收到的标签或完整消息写入日志。

最小测试要覆盖哪些边界

测试重点不是证明机器上每次耗时完全相同，而是确认比较契约：相同摘要返回真，不同内容返回假，长度不同也返回假；HMAC 校验则要覆盖消息、密钥和标签的任意变化。

package digestcheck

import "testing"

func TestEqualDigest(t *testing.T) {
	// 三组输入对应匹配、内容差异和长度差异。
	cases := []struct {
		name string
		a, b []byte
		want bool
	}{
		{"same", []byte("abcdef"), []byte("abcdef"), true},
		{"different", []byte("abcdef"), []byte("abcdeg"), false},
		{"shorter", []byte("abcdef"), []byte("abcde"), false},
	}
	for _, tc := range cases {
		if got := EqualDigest(tc.a, tc.b); got != tc.want {
			t.Fatalf("%s: got %v, want %v", tc.name, got, tc.want)
		}
	}
}

最后可以运行 go test ./... 检查返回值和调用关系。这个命令验证的是逻辑边界，不是对生产环境时序侧信道风险做完整测量。

迁移时的速查结论

常见问题

ConstantTimeCompare 会隐藏长度吗？

不会。它在长度不一致时会立即返回 0，因此长度必须是公开且可接受的协议边界，或者由调用方先做一致性处理。

可以用 bytes.Equal 比较密码摘要吗？

不建议把普通比较用于需要防止时序侧信道的摘要或 MAC 校验。等长摘要用 ConstantTimeCompare，HMAC 用 hmac.Equal 更符合 API 语义。

只换比较函数就完成安全校验了吗？

没有。摘要算法、密钥管理、输入编码、错误响应和日志策略同样重要；常量时间比较只解决其中的内容比较环节。