Go crypto/subtle.ConstantTimeSelect 怎么避免分支泄露：常量时间条件选择的使用边界

处理密钥、令牌或口令派生结果时，最容易被忽视的不是函数能不能返回正确值，而是秘密相关的条件有没有进入普通分支。Go 的 crypto/subtle.ConstantTimeSelect 可以在两个整数结果之间做常量时间选择，但前提是条件值和输入输出都符合它的契约；把它当成“任何 if 都能替换”的性能工具，反而会制造错误的安全感。

先把 ConstantTimeSelect 的契约写清楚

函数签名很短：func ConstantTimeSelect(v, x, y int) int。它在 v == 1 时返回 x，在 v == 0 时返回 y。这里的 v 不是任意布尔值的自然替身，调用方应先把比较结果规范成 0 或 1。

package securechoice

import "crypto/subtle"

func chooseScore(equal bool, good, bad int) int {
    v := 0
    if equal {
        v = 1
    }
    return subtle.ConstantTimeSelect(v, good, bad)
}

这个例子只说明 API 契约，不代表前面的 if equal 已经是常量时间比较。真实代码里，equal 应来自适合场景的常量时间比较函数，或者来自已经完成规范化的掩码。

用掩码选择结果，而不是选择执行路径

常见场景是比较两个固定长度的摘要，再根据比较结果选择成功值或失败值。选择动作本身应该只改变整数结果，不应该因为秘密不同而走不同的数组索引、日志格式或错误分支。

func selectStatus(a, b []byte) int {
    if len(a) != len(b) {
        return 0
    }

    equal := subtle.ConstantTimeCompare(a, b)
    return subtle.ConstantTimeSelect(equal, 1, 0)
}

ConstantTimeCompare 返回 0 或 1，因此可以直接作为这里的选择条件。长度检查放在比较之前是公开输入的结构判断；如果长度本身也属于秘密，就需要重新设计协议，不能仅靠 ConstantTimeSelect 补救。

三个看似正确的写法其实不等价

第一种误用是把任意非零值当成条件。调用方如果把位运算结果、错误码或长度差直接传入，代码阅读者很难确认它是否永远只会产生 0 和 1。安全函数的参数契约应该在调用点可见，必要时显式做归一化。

第二种误用是只替换最后一行，前面仍用普通 if 比较秘密字节，或者在选择后根据结果写入不同长度的响应。局部常量时间不等于整条请求路径常量时间。

第三种误用是把它用于数组下标、内存地址或复杂结构。函数返回的是 int，并不会把两个对象的读取、拷贝、分配和释放变成相同成本。需要选择字节串时，应使用专门设计过的常量时间操作，并逐项检查长度和容量。

从编译和测试两侧验收

最小验收先验证语义，再验证输入边界。不要只写一个 happy path；至少覆盖 v=0、v=1、意外非零值的处理策略，以及两个候选值相同和不同的情况。

func TestChooseScore(t *testing.T) {
    tests := []struct {
        name string
        v, x, y int
        want int
    }{
        {"zero", 0, 11, 22, 22},
        {"one", 1, 11, 22, 11},
    }
    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            if got := subtle.ConstantTimeSelect(tt.v, tt.x, tt.y); got != tt.want {
                t.Fatalf("got %d, want %d", got, tt.want)
            }
        })
    }
}

再用 go test ./... 和 go vet ./... 检查调用链，确认没有因为调试日志、错误拼接或额外的普通分支把秘密重新暴露。若场景属于认证、签名或密钥处理，优先使用标准库已有的高层 API；只有在明确知道算法边界时才下沉到 crypto/subtle。

常见问题

ConstantTimeSelect 能替代普通 if 吗？

不能。它只适合在两个整数结果之间做选择，且调用方要保证条件值符合约定。它不负责执行两个分支里的操作，也不改变之前的比较和之后的输出路径。

v 传入 2 会发生什么？

不要把非 0 值的行为当作业务契约。调用点应把条件规范成 0 或 1，再用测试固定边界；如果当前结果来自位运算，要先确认其范围，而不是凭经验直接传入。

用了 ConstantTimeCompare 就绝对安全了吗？

也不是。比较函数只覆盖比较动作。长度暴露、错误响应差异、日志、缓存和后续数据库查询仍可能泄露信息，最终要按整条认证路径验收。

小结

ConstantTimeSelect 的价值在于把一个明确的整数选择动作从普通条件路径中抽出来。正确用法是先确认秘密边界，再把条件规范为 0 或 1，最后用测试和调用链检查验证它没有被前后的普通分支抵消。若需求已经涉及完整认证或密码协议，优先采用标准高层实现，不要用一个小函数替代安全设计。