Go crypto/subtle.WithDataIndependentTiming 如何包住敏感计算：启用范围、嵌套调用与兼容降级

做口令、令牌或密钥材料校验时，真正容易被误解的不是 subtle.ConstantTimeCompare，而是“把它放进 WithDataIndependentTiming 就安全了”这句话。这个包装器只负责在一段敏感计算期间启用架构相关的独立时序能力，算法本身仍必须使用常量时间操作；在 Go 1.24 之前，则要把它降级为一个保持调用形状的兼容函数。

WithDataIndependentTiming 是敏感计算的运行时保护边界，不是常量时间算法生成器。先保证比较、选择和循环本身没有按秘密数据变化，再用它包住最小范围。

先分清两层保护：算法时序与处理器时序

subtle.ConstantTimeCompare 解决的是比较逻辑不要因为字节值不同而提前退出；WithDataIndependentTiming 解决的是特定架构可能根据输入影响某些指令时序的问题。两者是相邻的两层，不是替代关系。

package tokencheck

import "crypto/subtle"

func sameToken(want, got []byte) bool {
	if len(want) != len(got) {
		return false
	}
	matched := false
	subtle.WithDataIndependentTiming(func() {
		matched = subtle.ConstantTimeCompare(want, got) == 1
	})
	return matched
}

这里的真实调用链是 sameToken 进入 WithDataIndependentTiming，再调用 ConstantTimeCompare，最后把比较状态返回给调用方。长度检查放在包装器外，是为了让保护边界只覆盖固定长度的敏感比较；如果业务要求隐藏长度，也要在更上游统一输入长度，不能靠这个函数补救。

把包装器收窄到固定长度的敏感区间

包装器接收一个无参数闭包，进入闭包前启用能力，闭包返回后关闭。适合放入闭包的是已经完成长度和格式判断的比较、掩码选择或固定轮次计算；不适合把网络请求、日志拼接、字符串解析等不确定工作整段塞进去。

func verifySignature(expected, actual []byte) bool {
	if len(expected) != len(actual) {
		return false
	}
	result := 0
	subtle.WithDataIndependentTiming(func() {
		result = subtle.ConstantTimeCompare(expected, actual)
	})
	return result == 1
}

核对点只有一个：result 在闭包内完成比较，闭包返回后才读取结果。不要在闭包里根据 result 立刻分支，也不要把错误信息拼接进敏感区间；这些动作应回到包装器外，并且不能泄露秘密值。

嵌套调用和 goroutine 继承，边界要写进评审清单

官方文档明确允许嵌套调用。嵌套并不会让内部代码自动获得新的业务语义，它只是保持外层能力在内层继续有效。更值得留意的是：闭包启动的 goroutine 会继承独立时序状态，并在自己的生命周期内继续保持。

subtle.WithDataIndependentTiming(func() {
	subtle.WithDataIndependentTiming(func() {
		_ = subtle.ConstantTimeCompare(expected, actual)
	})
})

工程上不建议为了“保险”层层嵌套。每多一层，就多一个需要解释的边界；除非底层库也有独立封装，否则一层包住最小敏感区间更易测试。若闭包启动 goroutine，还要检查 goroutine 是否会接触不应继承该状态的长生命周期任务。

旧版本兼容：保留调用形状，不伪造安全能力

项目若要同时支持 Go 1.23 和 Go 1.24，可以把业务调用固定为一个本地函数，再用构建约束提供两个实现。旧版本实现只能同步执行闭包，不能声称启用了处理器级独立时序。

// dit_legacy.go
package tokencheck

func withDataIndependentTiming(f func()) {
	f()
}

// dit_go124.go 使用 Go 1.24 构建约束时：
// func withDataIndependentTiming(f func()) {
//     subtle.WithDataIndependentTiming(f)
// }

实际项目应按模块的 go 版本和构建约束规则拆分文件，并在 CI 中分别编译目标版本。兼容层的价值是让业务代码只依赖一个稳定调用形状；它不应该把旧版本包装成和新版本完全等价的运行时保证。

三个容易误用的地方

• 把变长算法包进去：包装器不会改变按输入长度循环的代码，固定轮次与常量时间实现仍由业务负责。
• 只看 Arm64 结果：官方文档说明当前 Arm64 FEAT_DIT 会启用 PSTATE.DIT，其他架构目前执行闭包但没有额外副作用，测试不能只在一台机器上下结论。
• 保护范围过大：网络、磁盘、日志和锁竞争会让测试噪声变大，也会让审查者难以确认哪段计算真正需要保护。

用单元测试验证调用边界，而不是测一个漂亮的耗时数字

测试重点应放在结果一致性、长度边界、嵌套调用和兼容构建上。官方源码测试也覆盖了从闭包启动 goroutine 后状态仍可见的行为。不要把一次本机微秒差异当成密码学证明；它最多只能帮助发现明显的回归。

func TestSameToken(t *testing.T) {
	want := []byte("fixed-token")
	if !sameToken(want, []byte("fixed-token")) {
		t.Fatal("equal tokens rejected")
	}
	if sameToken(want, []byte("other-token")) {
		t.Fatal("different tokens accepted")
	}
	if sameToken(want, []byte("short")) {
		t.Fatal("different lengths accepted")
	}
}

相关问题

WithDataIndependentTiming 能替代 ConstantTimeCompare 吗？

不能。前者是架构相关的运行时保护，后者才是比较逻辑的常量时间工具；敏感比较通常需要两者各司其职。

这个函数在非 Arm64 机器上会失效吗？

不会失效，但当前官方文档说明其他架构执行闭包时没有额外副作用。代码仍可统一调用，不能把它当成跨架构相同的硬件保证。

为什么不把整个请求处理函数包进去？

因为请求处理里常有网络、日志、解析和可变长度分支。只包住固定长度敏感计算，边界更清楚，测试和代码审查也更可靠。

落地前的检查清单

1. 确认模块最低 Go 版本，决定是否需要兼容实现。
2. 确认敏感计算使用了常量时间比较或选择，且轮次不随秘密输入改变。
3. 把 WithDataIndependentTiming 放在最小闭包内，记录嵌套与 goroutine 行为。
4. 在目标架构和旧版本构建矩阵中运行结果、边界和回归测试。