if 和 == 在密码学代码中危险，因其引发定时侧信道攻击：CPU执行时间随密钥字节变化，攻击者通过纳秒级计时可推断密钥匹配情况；须用恒定时间编程，如掩码运算、固定循环、编译器屏障及硬件特性禁用。
为什么 if 和 == 在密码学代码里很危险
因为现代 CPU 会根据分支结果跳过指令或提前终止比较，导致执行时间随输入数据（比如密钥字节）变化。攻击者通过高精度计时（纳秒级）反复测量 memcmp、== 或条件分支的耗时，就能推断出密钥中哪些字节匹配、哪些不匹配——这正是定时侧信道攻击的核心原理。
典型错误写法：
if (secret_key[i] == input_byte) { /* do something */ } 这段代码在 secret_key[i] 等于或不等于 input_byte 时，CPU 流水线行为、缓存命中/未命中、分支预测成功率都不同，时间差虽小但可测。
实操建议：
- 禁用所有依赖秘密数据的分支：包括
if、while、for的边界依赖秘密值（如for (int i = 0; i 不行） - 禁用短路运算符：
&&、||会导致执行路径不一致 - 避免调用非恒定时间的库函数：
memcmp、strcmp、std::string::operator==全部不可信；OpenSSL 提供了CRYPTO_memcmp，libsodium 有sodium_memcmp，必须用它们
用位运算和掩码替代分支判断
核心思路是把“是否相等”转化为一个全 0 或全 1 的掩码整数（如 uint32_t），再用按位与/或/异或做数据选择，而非 if。
立即学习“C++免费学习笔记（深入）”；
例如，恒定时间比较两个字节：
inline uint8_t ct_eq_u8(uint8_t x, uint8_t y) {
uint8_t diff = x ^ y;
return ((diff | -diff) >> 7) & 1; // 若 diff == 0 返回 1，否则 0
} 这里 -diff 是补码，diff | -diff 在 diff != 0 时最高位必为 1，右移 7 位后得到 0 或 1，全程无分支。
再比如恒定时间条件赋值：
uint32_t mask = ct_eq_u8(a, b); // 0 or 0xFF...FF result = (mask & x) | (~mask & y); // 等价于 mask ? x : y注意必须用
~mask 而非 1-mask，因为掩码可能是全 1（0xFFFFFFFF），而 1-mask 会溢出或符号扩展出错。
关键点：
- 所有中间变量类型要足够宽（推荐
uint32_t或uint64_t），避免隐式符号扩展干扰掩码 - 编译器优化可能破坏恒定时间性：加
volatile不可靠，正确做法是用__attribute__((optimize("O0")))或更稳妥地——用asm volatile ("" ::: "r0", "r1")插入编译器屏障（具体寄存器名依平台而定）防止重排和消除 - 别信“看起来没分支”：像
abs(x-y)或!!(x^y)仍可能被编译成条件跳转，务必反汇编验证（objdump -d或 Compiler Explorer）
循环长度必须固定，且索引不能依赖秘密数据
密码算法常需遍历密钥或状态数组，但若循环次数由密钥长度决定（比如私钥 bit 数），攻击者可通过测量总耗时反推密钥长度，进而缩小爆破空间。RSA 私钥指数、ECC 私钥标量都属此类敏感长度。
安全做法是预设最大长度并恒定执行：
- 对 ECC 标量乘法：统一用最大支持位宽（如 256 位）做 256 次循环，每轮都执行点加/倍点，仅靠掩码控制是否“生效”
- 对 AES 密钥扩展：无论用户给 128/192/256 位密钥，都走完 14 轮（对应 256 位）的完整流程，冗余轮次用恒定时间空操作填充
- 禁止用
strlen或.size()获取秘密字符串长度；长度必须作为公开参数传入，且所有缓冲区按最大可能尺寸分配
一个易忽略的坑：std::vector 的 at() 会检查越界并抛异常（引发分支），而 operator[] 不检查但 UB 风险高。恒定时间代码中应直接用裸指针 + 预校验长度，或封装带掩码边界的访问器。
编译器和 CPU 层面的干扰项不能忽视
写了恒定时间逻辑，不代表运行时就真恒定了。现代 x86 CPU 的 Spectre/Meltdown 补丁、微码更新、频率调节（Intel SpeedStep）、L1D 缓存预取，都可能引入与数据相关的时间抖动。
应对策略：
- 禁用数据依赖的硬件特性：编译时加
-mno-avx、-mno-sse（AVX/SSE 指令在某些 CPU 上有数据依赖延迟）；Clang/LLVM 可用-fsanitize=cfi但注意它本身不恒定时间 - 内存访问必须对齐且模式固定：避免
std::vector<uint8_t></uint8_t>动态分配导致地址随机化；优先用std::array或静态缓冲区，并用std::align手动对齐到 64 字节（缓存行大小） - 最可靠的实践是“全部加载、全部计算、最后掩码输出”：比如 HMAC 中先将整个密钥复制到固定大小缓冲区（不足补零，超长则哈希截断），再对齐加载进寄存器，全程不出现“密钥在哪结束”的判断点
真正棘手的是，同一份 C++ 代码在不同 CPU 微架构（Skylake vs. Zen3）、不同内核版本、甚至不同 BIOS 设置下，侧信道泄漏程度都可能不同。没有银弹，只有持续测试：用 rdtscp 指令采样周期数，配合统计检验（如 t-test）确认两组不同密钥输入下的时间分布无显著差异。
