常数时间性质统计检验的功效标定：dudect 方法在消费级 CPU 上对可控泄漏的检出曲线与假阳性率

1 · 研究问题

以时序泄漏检测工具 dudect 为代表的"黑盒统计检验"方法，在噪声远高于服务器的消费级笔记本 CPU 上，对可控幅度的人工植入泄漏的检出功效（statistical power）随测量样本量如何变化？在已知常数时间的参考实现上，该方法在常用阈值下的假阳性率是多少——换言之，公开报告中"某实现未通过常数时间检验"的结论，需要多少样本量才能被认为可靠？

伦理与合规声明（写在方案首位）：本课题只做防御向测量，全部对象为学生本机上编译的开源密码库的公开 API；不针对任何在线服务、不采集任何第三方数据、不尝试恢复任何真实密钥、不开发任何攻击工具。产出物是检测方法的功效曲线与使用建议，属于安全测试方法学。

2 · 研究背景与空白

技术背景。 密码实现若其执行时间依赖于秘密数据（密钥、明文），攻击者就可能通过反复计时统计恢复秘密——这就是时序侧信道。防御手段是写"常数时间"代码：避免依赖秘密的分支与内存访问。验证一段代码是否常数时间有两条路：静态/符号分析（对二进制或中间表示做推理）与黑盒统计测量。Reparaz 等的 dudect（《Dude, is my code constant time?》, DATE 2017, ePrint 2016/1123）属于后者：对两类输入（例如全零向量 vs 随机向量）各测大量执行时间样本，用 Welch t 检验判断两个时间分布是否有统计显著差异；原型仅约 300 行 C 代码，开源于 oreparaz/dudect。它的优势是不依赖任何静态分析、直接反映目标平台的真实行为；公开文献同时明确指出它的弱点：对现代计算机系统中普遍存在的噪声高度敏感。近期还出现了基于低层代码轨迹动态分析的常数时间验证工作（arXiv:2604.16832）与单轨迹侧信道漏洞自动检测方向（arXiv:2304.02102），CRoCS 维护的 ct-tools 站点收录了这一类工具的横向清单。

空白在于：dudect 类方法被广泛使用并被用来给出"某实现不是常数时间"的判断，但公开文献里没有系统的功效标定——即"泄漏幅度多大、样本量多少时，这个检验有多大概率检出"，以及"在确定常数时间的代码上，它多久会误报一次"。没有功效曲线，一个"未检出泄漏"的结果无法区分"确实没有泄漏"与"样本量不足"。这个空白属于"评价维度转换"，且它具有学生课题少见的优点：可以人工制造已知真值——把一段常数时间代码改成"泄漏 N 个时钟周期"的可控版本，真值完全已知，因此功效与假阳性率都能被精确测量，而不需要任何真实漏洞。算力上完全无门槛。

3 · 可检验假设

• H1：在消费级笔记本上，dudect 的检出功效随植入泄漏幅度 Δ（以时钟周期计）与样本量 N 呈可标定的关系：达到 80% 检出功效所需的样本量 N₈₀ 与 Δ 的平方成反比（即 N₈₀ · Δ² ≈ 常数，符合 t 检验的理论标度）。判据为跨 ≥ 6 个 Δ 档位的双对数拟合斜率落在 [−2.4, −1.6]。若偏离该区间，说明噪声结构不满足检验假设，需要改用非参数或分位数方法——这同样是重要结论。
• H2：在已知常数时间的参考实现上，dudect 默认判据（|t| > 4.5 判为非常数时间）的假阳性率在笔记本上显著高于名义水平：≥ 20 次独立完整运行中至少 15% 误判为非常数时间。若假阳性率 ≤ 5%，H2 被否证，方法在噪声平台上的稳健性获得一次独立支持。

4 · 量化验收标准

1. 方法学校验（硬门槛）：用自建测量框架重现 dudect 原论文/仓库中给出的示例结果——即在其自带的"确定泄漏"示例（如朴素的非常数时间内存比较）上检出泄漏、在其自带的常数时间示例上不检出，且 t 统计量随样本量增长的轨迹形态与官方示例一致（趋势方向与量级一致，绝对值跨平台不可比）。同时用一个独立实现的 Welch t 检验（Python/SciPy）对同一批原始时间样本复算 t 值，与 dudect 内部计算的偏差 ≤ 1%。这一步不过关，后续全部结论无效。
2. 真值构造的可控性：人工泄漏必须通过一个参数化的延迟注入实现（例如依据秘密位数决定执行的空转循环次数），且注入幅度须用独立的直接计时实测标定（报中位数与 IQR），标定值与设定值的偏差 ≤ 10%。未经标定的"泄漏幅度"不得用于功效曲线。
3. 功效与假阳性的统计口径：功效曲线的每个点（Δ × N 组合）用 ≥ 30 次独立完整实验（每次重新采样、重新计算）估计，报检出比例与 Clopper–Pearson 精确二项置信区间；假阳性率用 ≥ 50 次在常数时间参考实现上的独立运行估计，同样给精确置信区间。明确写明不用单次运行的 t 值下结论——单次 t 值正是本课题要质疑的做法。
4. 测量环境控制：固定 CPU 频率、绑核、禁用 Turbo 与 SMT、记录温度与频率日志、每次运行前预热并丢弃预热段；同时报告"未控制环境"（默认设置、允许后台负载）下的对照结果——两种环境的功效差异本身就是本课题的核心交付物之一。全部延迟数据报中位数与 IQR，不报均值。
5. 覆盖面：至少 3 个开源密码库的至少 5 个原语（例如常数时间内存比较、AES 软件实现、Curve25519 标量乘、RSA 模幂的常数时间与非常数时间变体）；每个原语同时测其"库自带版本"与"人工注入泄漏版本"，前者用于假阳性/漏检评估，后者用于功效曲线。
6. 方法对照：把 dudect 的结果与至少一种独立机制的检测方法对照——首选基于动态污点/未初始化内存追踪的 ctgrind / Valgrind-MemSan 方案或 TIMECOP（可用性需核实）。两种方法给出不同结论的原语要逐一分析原因。
7. 可复现性：全部测量代码、泄漏注入补丁、原始时间样本（压缩存档）、统计脚本开源；一键重跑脚本；固定种子；完整披露硬件、OS、编译器版本与编译选项（编译选项极其关键：优化级别会改变是否常数时间，必须逐一记录）。

5 · 数据与工具

用途	来源 / 工具
时序泄漏检测工具	dudect（GitHub oreparaz/dudect，约 300 行 C，零依赖）。仅用于校验与对比，不计入本项目贡献
对照检测方法	ctgrind（Langley，基于 Valgrind）/ Valgrind MemorySanitizer 方案；TIMECOP（SUPERCOP 工具链的一部分）；CRoCS ct-tools 站点（crocs-muni.github.io/ct-tools）提供工具清单与状态。具体可用性与安装难度需核实，列为风险项
被测密码实现	libsodium（常数时间为设计目标，含 sodium_memcmp、Curve25519）；mbedTLS（含常数时间与传统实现的对照配置）；BearSSL（明确的常数时间设计文档）。全部开源、可本地编译。仅作为测量对象，不评价其安全性质，不声称发现任何漏洞
泄漏注入	自行实现的参数化延迟注入补丁（依赖秘密位的空转循环 / 依赖秘密的查表访问两种机制各一套）
计时与环境控制	rdtscp / clock_gettime；taskset、cpupower、turbostat（笔记本平台上的可用性需核实）
统计	Python + SciPy（Welch t 检验、Clopper–Pearson 区间）+ statsmodels（功效分析）+ Matplotlib
算力	纯 CPU，内存 < 1 GB。单次 dudect 运行数十秒到数分钟；总工作量约 6 Δ 档 × 6 N 档 × 30 重复 × 5 原语 ≈ 数十机时，可夜间批跑。超出范围：硬件功耗/电磁侧信道测量（需示波器与探头）不在本课题范围内，须在正文明确声明

6 · 方法路径

1. 装环境，编译 dudect 与其自带示例，复现"泄漏示例检出 / 常数时间示例不检出"这一基本行为；用 SciPy 独立复算 t 值完成验收第 1 条。
2. 核实工具能力边界（本课题的关键风险步）：对照方法（ctgrind / TIMECOP）能否在本机安装运行；cpupower/turbostat 在笔记本上是否可用；编译器优化级别对被测函数是否引入或消除分支（须用反汇编逐一确认，这一步不能靠猜）。
3. 实现并标定参数化泄漏注入：用直接计时实测每个 Δ 档位的真实幅度（中位数与 IQR），确认与设定值偏差 ≤ 10%；未达标的档位重新设计。
4. 建立测量框架：环境控制脚本、独立完整实验的自动重复、原始时间样本落盘（保留全分布，不做在线聚合）、温度与频率日志。
5. 执行功效扫描（Δ × N × 30 次独立实验）与假阳性扫描（常数时间实现 × ≥ 50 次独立运行），在"受控环境"与"默认环境"两种条件下各做一遍。
6. 分析：功效曲线与 N₈₀ 的 Δ 标度拟合（H1）、假阳性率与精确置信区间（H2）、受控 vs 默认环境的对照、双成本口径（等样本数 / 等墙钟时间预算下的检出率）。
7. 独立交叉校验：（a）用对照检测方法（ctgrind 类）对同一批原语给出判定，与 dudect 结果做一致性分析（Cohen's κ）并逐一解释分歧；（b）在另一台不同微架构的机器上重跑功效曲线的关键档位，检验 N₈₀·Δ² 标度是否跨平台成立。

7 · 新颖性边界

本课题不声称：不提出新的泄漏检测方法，不实施任何攻击，不恢复任何密钥，不声称发现任何开源库的安全漏洞（若测量中出现异常，正确做法是按各项目的安全披露流程报告，而不是写进论文作为发现），不做硬件侧信道测量。dudect、ctgrind/TIMECOP 与全部被测密码库均为他人工作，标注为对照基准，不计入本项目贡献。

已有工作完成了什么：Reparaz 等（DATE 2017 / ePrint 2016/1123）提出并开源了 dudect，用 Welch t 检验对两类输入的执行时间分布做统计比较，明确说明该方法不依赖静态分析而依赖目标平台上的实测，同时指出其对现代系统噪声高度敏感；近期工作把常数时间验证推进到低层代码轨迹的动态分析（arXiv:2604.16832）与单轨迹漏洞自动检测（arXiv:2304.02102）；CRoCS 的 ct-tools 汇总了这一类工具。这些工作本项目引用而不重复声称。

本项目的贡献：给出 dudect 类黑盒方法在消费级噪声平台上的功效曲线与假阳性率标定——用人工可控泄漏构造已知真值，量化"检出需要多少样本"与"不检出意味着什么"。主结论是这条标定曲线与由它导出的使用建议（例如"报告未检出泄漏时必须同时报告该样本量下可检出的最小泄漏幅度"），不是任何新工具。

为什么有价值：目前大量安全实践直接引用 dudect 的单次运行结论。若功效标定显示常用样本量只能检出 ≫ 实际攻击所需的泄漏幅度，那么"通过 dudect 检验"这一说法本身需要附带条件；若方法比预想稳健，则为其广泛使用提供一次独立背书。

风险提示：笔记本平台的噪声可能大到使功效曲线在可行样本量内根本不出现拐点。这一结果本身即是重要结论（"该方法在此类平台上不可用"），但必须给出精确二项置信区间证明本实验设计确有分辨力，且必须在受控与非受控两种环境下都做，避免把"没配置好环境"误报为"方法无效"。

8 · 决策门槛（go / no-go）

• 第 5 周：合规与选题边界确认。指导教师须书面确认本课题的防御向定位与"不实施攻击、不做漏洞披露式结论"的边界；同时确认参赛材料中不含任何可直接用于攻击的产物。此项不通过则整条路线不启动（应改选 K03 或 K07）。
• 第 8 周：泄漏注入标定门槛。若参数化延迟注入无法被编译器保留（优化掉空转循环）或标定偏差 > 10%，降级路径 A：改用"依据秘密位选择不同缓存行的查表访问"作为泄漏机制（不可被优化消除，且幅度由缓存缺失代价自然标定）。功效曲线框架完全保留，仅泄漏机制从计算型改为访存型，须在正文声明并讨论两种机制的差异。
• 第 12 周：对照检测方法的可用性必须核实完毕——这是需要提前确认而非边做边发现的事项。若 ctgrind/TIMECOP 均无法运行，降级路径 B：对照方法改为"源码级人工审计"——由学生对每个被测原语逐行判定是否存在依赖秘密的分支/访存，并给出明确、可复现的判定规则与判定记录（双人独立判定并报 Cohen's κ）。证据强度略降但完全自洽，主结论不变。
• 第 20 周：功效曲线必须出现可用拐点。若在最大可行样本量下所有 Δ 档位的检出率都接近 0 或都接近 1，降级路径 C：重新设计 Δ 档位（用第 8 周标定的实测幅度做对数等距重排），并把重心从"功效曲线"转向"环境控制对检出能力的贡献"——即受控 vs 默认环境的对照，这部分不依赖拐点位置且本身缺少公开数据。主结论框架（方法的可信度标定）保留。
• 第 30 周：假阳性扫描完成且 H2 有明确判定。若进度不足，降级路径 D：被测原语从 5 个减为 3 个（常数时间内存比较、AES 软件实现、Curve25519 标量乘），密码库从 3 个减为 2 个，重复次数保持不变。
• 预算裁剪顺序：密码库数量（下限 2）→ 原语数量（下限 3）→ Δ 档位数（下限 4）→ （绝不裁剪）独立完整实验的重复次数与环境控制。
• 选择前提：仅在学生能读写 C、理解假设检验的功效概念、且指导教师认可防御向边界时才启动。若学生对"我要做黑客项目"有期待，这条路线应当明确劝退——本课题的全部内容是测量方法学。

---