Go crypto/subtle.ConstantTimeSelect 怎么避免条件分支泄露：布尔选择与固定时间路径

在需要根据比较结果选择两个敏感值时，直接写 `if equal { return secretA }` 会让代码路径随着秘密相关输入变化。Go 的 crypto/subtle.ConstantTimeSelect 提供了一个更窄的工具：当选择值是 1 时返回 x，是 0 时返回 y，而且调用方不必用条件分支来完成这次整数选择。

把 ConstantTimeEq 的 0/1 结果交给 ConstantTimeSelect，适合在两个已经算好的整数候选值之间做固定路径选择；它不负责校验输入，也不能替代完整的协议级侧信道设计。

ConstantTimeSelect 解决的是哪一次选择

这个函数的签名是 ConstantTimeSelect(v, x, y int) int。官方契约很明确：v == 1 返回 x，v == 0 返回 y；如果 v 是 2、-1 或其他整数，行为未定义。这里的“固定时间”应该理解为选择操作不依赖 v 走普通的条件跳转，而不是承诺整段程序的耗时完全相同。

比较结果可以由 ConstantTimeEq 产生。它返回整数 1 或 0，正好满足选择器的输入要求：

package main

import (
    "crypto/subtle"
    "fmt"
)

func chooseToken(got, expected int32, validToken, fallback int) int {
    same := subtle.ConstantTimeEq(got, expected)
    return subtle.ConstantTimeSelect(same, validToken, fallback)
}

func main() {
    fmt.Println(chooseToken(7, 7, 200, 401))
    fmt.Println(chooseToken(7, 9, 200, 401))
}

这段代码的关键节点是 ConstantTimeEq、ConstantTimeSelect、validToken 和 fallback：先得到 0/1，再从两个已存在的整数中选出结果。运行输出应为 200 和 401。注意，示例里的整数只是为了说明数据路径，不代表把认证结果直接编码成 HTTP 状态码就完成了安全设计。

为什么要先算好两个候选值

下面这种写法容易把“选择”与“计算”混在一起：

if subtle.ConstantTimeEq(got, expected) == 1 {
    return buildSecretResult(input)
}
return buildFallbackResult(input)

即使把比较函数写成常数时间，if 仍然让控制流随比较结果改变，而且两条路径可能访问不同的内存、调用不同的函数或在不同位置提前结束。更稳妥的边界是先准备两个候选整数，再只让选择器决定返回哪一个：

validToken := 200
fallback := 401
same := subtle.ConstantTimeEq(got, expected)
result := subtle.ConstantTimeSelect(same, validToken, fallback)
return result

图中只保留正文实际出现的 if、ConstantTimeSelect、validToken 和 fallback 四个节点。它表达的是控制流差异被收窄为一次整数选择，不是说所有前置计算都天然固定时间。

哪些误用会让安全结论失真

把任意整数都当作选择值

ConstantTimeSelect(2, x, y) 不表示“非零就选 x”。文档已经把非 0/1 输入列为未定义行为，所以不要把普通布尔表达式、计数器或错误码直接传进去。需要比较时，使用返回 0/1 的 ConstantTimeEq、ConstantTimeByteEq 或符合契约的其他函数。

以为函数会隐藏候选值的计算成本

选择器只处理整数返回值。若 validToken 和 fallback 的构造过程不同，缓存访问、分配、循环次数或错误处理仍可能暴露差异。它不能把两个不对称的业务分支自动变成安全分支。

忽略长度和协议状态

ConstantTimeCompare 在切片长度不一致时会立即返回 0；认证协议还可能在解析长度、错误响应、重试次数和网络时序上泄露信息。选择器只能覆盖这里明确的整数选择，不要把它当成通用“安全模式开关”。

用测试核对输入契约和结果

测试重点不是证明所有机器上的纳秒数完全一致，而是把 0、1 和两个候选结果的契约固定下来，同时明确不允许的输入不在正常业务路径出现：

func TestChooseToken(t *testing.T) {
    tests := []struct {
        got, expected int32
        want          int
    }{
        {got: 7, expected: 7, want: 200},
        {got: 7, expected: 9, want: 401},
    }
    for _, tt := range tests {
        if got := chooseToken(tt.got, tt.expected, 200, 401); got != tt.want {
            t.Fatalf("got %d, want %d", got, tt.want)
        }
    }
}

如果选择值来自自定义计算，先在边界处把它规范化为 0 或 1，再进入 ConstantTimeSelect。对安全敏感代码，还应结合编译器、目标架构和协议整体做复核；一个单元测试只能确认返回值，没有能力证明不存在侧信道。

相关问答

ConstantTimeSelect 能替代 if 吗？

只能替代两个整数候选值的选择动作，不能替代包含副作用、错误处理或不同资源访问的完整业务分支。

v 传 true 或 false 可以吗？

函数参数是 int，不要依赖隐式转换；传入 0 或 1，或者使用返回 0/1 的 subtle 比较函数。

调用 ConstantTimeSelect 后就没有时序泄露了吗？

没有。输入长度、内存访问、分配、早返回、网络响应和协议状态都可能泄露信息，需要一起检查。

小结

ConstantTimeSelect 的价值在于把一个明确的整数选择动作从普通条件跳转中抽出来。实际使用时守住三条线：选择值严格为 0/1，两个候选值提前准备，最后再从整个协议和实现检查长度、资源访问及错误路径。这样得到的是可核对的安全边界，而不是一句“用了 crypto/subtle 就安全”。