在测试运行中的密码学实现是否恒定时间时…

当你需要检测已编译的密码学实现是否存在时序泄漏、测量二进制时序方差或调查疑似时序攻击时使用。

适用场景

解决思路

1. 按四类工具选择：形式化验证（SideTrail、ct-verif、FaCT）用于证明无泄漏；符号执行（Binsec、pitchfork）用于找缓存时序漏洞并给出具体反例；动态分析（Memsan、Timecop）用于运行时追踪秘密数据流；统计分析（dudect、tlsfuzzer）用于测量真实执行时序差异。
2. 优先识别四类常见恒定时间违规模式：条件跳转（if(secret==1)、while(secret>0)）、依赖秘密的数组访问（lookup_table[secret]）、整数除法（secret/m）、移位操作（a<<secret）。
3. 无法避免上述模式时，使用掩码（masking）技术消除时序与秘密的相关性。
4. 按推荐工作流执行：先用 dudect 做快速统计检查；若发现泄漏，用 Timecop 定位根因；高保障场景再上形式化验证（ct-verif、SideTrail）；最后把 dudect 集成进 CI 持续监控。
5. 用 dudect 时：定义 DUDECT_IMPLEMENTATION 并 include "dudect.h"，实现 do_one_computation() 放置被测代码，实现 prepare_inputs() 用 randombit() 把输入分为固定类与随机类，用 Welch t-test 检测统计显著差异。
6. 用 Timecop 时：include "valgrind/memcheck.h"，用 poison(addr,len)（即 VALGRIND_MAKE_MEM_UNDEFINED）标记秘密，用 unpoison(addr,len)（即 VALGRIND_MAKE_MEM_DEFINED）解除标记，然后运行 valgrind --leak-check=full --track-origins=yes ./binary，Valgrind 会报告依赖未初始化值的条件跳转或内存访问。
7. Phase 1 初始评估：识别处理私钥、指数、nonce、口令哈希、认证令牌、加解密操作的代码；为加密函数写 dudect harness；用 timeout 600 ./ct_test 跑 5-10 分钟，观察 t-value，绝对值高表示泄漏。
8. Phase 2 详细分析：若 dudect 检出泄漏，用 Timecop poison() 标记秘密变量，在 Valgrind 下运行定位确切行号，对照四类违规模式，并用 objdump -d 检查汇编中是否出现条件分支。
9. Phase 3 修复：用按位运算的恒定时间选择替换条件分支；使用恒定时间比较函数；用恒定时间替代或掩码替换数组查表；确认编译器没有把恒定时间代码优化掉。
10. Phase 3 复验：再次运行 dudect 至少 30 分钟；在不同编译器和优化级别下测试；在不同 CPU 架构上测试。
11. Phase 4 持续监控：把 dudect 测试加入测试套件，CI 中固定运行 5-10 分钟，检出泄漏则让构建失败。
12. 优化技巧：用 taskset -c 2 把 dudect 固定到隔离 CPU 核以减少 OS 噪声；测试 gcc、clang、MSVC 多种编译器；长时间运行（数小时）提高统计置信度；harness 中尽量减少非加密代码以降低噪声；用 objdump -d 检查汇编；测试时使用 -O3 -march=native 匹配生产优化级别。
13. 避免常见错误：不要只测一种输入分布（应测固定-随机、固定-不同固定等多种）；不要跑 dudect 少于 1 分钟（应 5-10 分钟以上）；不要忽略编译器优化级别（-O0 可能掩盖 -O3 下的泄漏）；不要只在单一架构测试（x86 与 ARM 时序特性不同）；Timecop 中不要标记过多内容为秘密（只标记真正的秘密如密钥，不标记公开数据）。

适用边界 · 注意事项

• 代码不处理秘密数据时
• 处理无秘密输入的公开算法时
• 只关注非加密的性能优化时序需求时
• 需要静态检查编译器输出时（应使用 constant-time-analysis 插件）