比较两个字节切片是否相等，在大多数业务代码里用 bytes.Equal 就足够了。不过一旦这些字节承载的是密码哈希、消息认证码或会话令牌，普通比较就可能把秘密暴露给攻击者。ConstantTimeByteEq 正是 Go 标准库为这种高风险比较提供的专用工具。
一、为什么普通比较会泄露信息
普通字符串或字节切片比较通常会做短路优化：从第一个字节开始逐个比较，一旦发现不同就立即返回。这种优化的本意是减少无谓计算，但它让比较耗时与内容前缀匹配长度直接相关。如果攻击者能够反复提交候选值并测量服务器响应时间，就可以像猜密码一样逐字节逼近真实值。
设想一个验证 API 令牌的场景。服务端把用户提交的令牌与数据库中的正确值放在一起比较，代码可能写成：
func CheckToken(userToken, correctToken []byte) bool {
return bytes.Equal(userToken, correctToken)
}
假设 correctToken 的前三个字节是 0x4A、0x1F、0x93。攻击者先提交以 0x00 开头的令牌，比较器在第一个字节就返回 false；接着提交以 0x4A 开头的令牌，比较器会继续检查第二个字节，耗时略长。通过大量重复测量并消除网络噪声，攻击者可以确认第一个字节是 0x4A，然后继续推断第二个字节。最终，原本需要天文数字次暴力尝试的 256 字节令牌，可能只需几百次请求就被还原。
这种攻击称为时序侧信道攻击。它不利用算法弱点，而是利用实现方式导致的物理特征差异。只要比较逻辑存在数据依赖的提前退出，耗时就会泄露信息。因此，安全敏感的比较必须做到无论内容如何，执行时间都保持一致。
二、ConstantTimeByteEq 的实现思路
Go 标准库 crypto/subtle 包提供的 ConstantTimeByteEq 就是为了解决这个问题。它的核心思想是：遍历两个字节切片的所有字节，用异或运算检查差异，并把差异累积到一个变量中，最后统一返回结果。整个过程不提前退出，循环次数只由切片长度决定，与内容无关。
下面这段代码展示了其简化的实现逻辑，用于帮助理解原理：
func ConstantTimeByteEq(x, y []byte) int {
if len(x) != len(y) {
return 0
}
var v byte
for i := 0; i < len(x); i++ {
v |= x[i] ^ y[i]
}
// 如果 v 为 0，说明所有字节都相等，返回 1
// 这里使用位运算把非 0 的 v 映射成 0，把 0 映射成 1
return int((uint32(v) - 1) >> 31)
}
可以看到，x[i] ^ y[i] 在两个字节相等时得到 0，不相等时得到非 0 值。通过按位或运算累积到 v，只要任意一个字节不同，v 最终就非 0。最后一步用减法与右移组合：当 v 为 0 时，uint32(0)-1 得到 0xFFFFFFFF，右移 31 位得到 1；当 v 非 0 时，减去 1 后最高位为 0，右移 31 位得到 0。这样既不使用分支判断，又保证了固定执行时间。
需要说明的是，标准库实际实现还可能使用更底层的平台优化或编译器内建函数，但原理一致。长度不相等时函数会直接返回 0，这一点在使用时需要额外注意：如果长度本身也是秘密的一部分，直接暴露长度差异同样可能被利用。更稳妥的做法是先比较哈希值或使用固定长度格式。
三、实际使用场景与误用提醒
在认证、签名校验、消息完整性检查等场景中，ConstantTimeByteEq 或功能相近的 hmac.Equal 是推荐选择。例如，在比较用户提交的 API 签名时，可以先计算 HMAC，再用恒定时间比较：
import (
"crypto/hmac"
"crypto/sha256"
)
func ValidSignature(message, signature, key []byte) bool {
mac := hmac.New(sha256.New, key)
mac.Write(message)
expectedMAC := mac.Sum(nil)
// hmac.Equal 内部使用恒定时间比较，避免时序泄露
return hmac.Equal(signature, expectedMAC)
}
需要特别强调的是，恒定时间比较的对象应是哈希或 MAC 输出，而不是原始密码。密码通常长度可变且需要经过哈希处理，直接比较原始输入会暴露长度信息。将密码哈希到固定长度的摘要后，比较就变得安全。
另一个常见误用是只关注比较函数，而忽略数据来源。例如，从数据库取数据、字符串拼接或编码转换都可能引入时间差异。安全的做法是在整个敏感路径上保持恒定时间，而不仅仅是最后一个比较操作。对于 Web 应用，还应考虑响应码、错误消息等旁路信息是否一致。
此外，编译器优化理论上可能把恒定时间比较重新转换成短路比较，尽管 Go 编译器目前不会对这类位运算做这种破坏性优化。为了保证安全，标准库使用 //go:noescape 或汇编实现等手段降低被优化风险。开发者不必重复造轮子，直接依赖标准库是更可靠的方案。
总结来说，ConstantTimeByteEq 解决了比较环节的时序泄露，但真正防住时序攻击需要结合哈希、固定长度输出和一致的错误处理。理解它的原理，能帮助你在编写安全敏感代码时做出正确判断。
Go语言时序攻击ConstantTimeByteEq修改时间：2026-09-18 17:06:23