Go subtle.ConstantTimeCompare 长度不同会返回什么：密钥校验中的边界判断

做签名或密钥校验时，subtle.ConstantTimeCompare 经常被当成“安全版的字符串比较”。它确实会按常量时间思路比较内容，但两个切片长度不同并不会继续比较，函数会直接返回 0。因此，长度校验不是多余的防御代码，而是判断输入是否符合协议边界的一部分。

subtle.ConstantTimeCompare 只有在两个字节切片长度相同且每个位置都相等时才返回 1；长度不同或内容不同都会返回 0。不要把它直接当作可处理任意字符串的通用比较器。

长度判断为什么决定了比较结果

这个函数接收两个 []byte，返回整数而不是布尔值。返回 1 表示两段数据完全相同，0 表示不相同。判断顺序很关键：长度不相等时，后面的内容比较没有意义，函数会先结束。

可以用下面的最小程序把三个结果分开看：

package main

import (
    "crypto/subtle"
    "fmt"
)

func main() {
    fmt.Println(subtle.ConstantTimeCompare([]byte("abc"), []byte("abc")))
    fmt.Println(subtle.ConstantTimeCompare([]byte("abc"), []byte("abd")))
    fmt.Println(subtle.ConstantTimeCompare([]byte("abc"), []byte("abcd")))
}

输出依次是 1、0、0。第三行不是“前 3 个字符相同所以通过”，因为协议值的长度本身就是输入约束。

长度相同后，内容是怎样被判断的

长度通过后，比较过程会把每个位置的字节差异累积起来，最后根据累积值给出 1 或 0。这种做法避免在遇到第一个不同字节时就提前返回，适合比较已经拿到本地的固定格式秘密值。

从数据路径看，最终结果只有 1/0 两种取值：相同内容落到 1，任一位置不同则落到 0。

这里要分清两个概念：常量时间比较减少的是“因内容位置不同而产生的提前退出差异”，它不会替你验证编码、长度、来源或密钥轮换状态。输入若来自 HTTP 头，仍然要先处理缺失、非法 Base64 和协议长度错误。

密钥校验时应该把长度当成协议规则

假设服务端保存的是固定 32 字节的摘要，收到请求后先完成 Base64 解码，再核对长度，最后比较内容。长度错误可以统一归入鉴权失败，避免把内部格式细节暴露给调用方。

func sameDigest(want, got []byte) bool {
    if len(want) != 32 || len(got) != 32 {
        return false
    }
    return subtle.ConstantTimeCompare(want, got) == 1
}

示例里的 32 必须来自实际协议或存储格式，不能因为“看起来安全”就随意改成另一个数字。若比较的是 HMAC 结果，应以所用摘要算法的输出长度为准，并在测试中覆盖缺失值、短值、长值和同长度错误值。

三个容易误判的边界

不要把返回值写成“非零都算成功”的宽松判断。当前实现返回的是 1 或 0，显式比较 == 1 更能表达 API 语义，也方便代码审查。

相关问题

ConstantTimeCompare 能直接比较 string 吗？

不能，它的参数类型是 []byte。转换时要注意数据编码保持一致，不能一边比较原始字节、一边比较十六进制文本。

长度不同需要先单独返回错误吗？

对外鉴权接口通常统一返回失败；内部诊断可以记录受控指标，但不要把期望长度或解码细节写入响应。

用了常量时间比较就能防住所有侧信道吗？

不能。网络响应、解码、日志、重试和上层分支也可能泄露差异，比较函数只是固定秘密值校验链中的一个环节。

把比较函数放在正确的位置

实际代码里先完成输入解码和格式校验，再用协议定义的长度做边界判断，最后调用 subtle.ConstantTimeCompare。测试至少覆盖相等、同长度不等、短输入、长输入和空切片五类情况；这样看到返回 0 时，才能知道是内容不符还是输入根本没有进入协议允许的形状。