用变异测试找出密码学实现测试向量覆盖盲区并生成新向量

当需要为密码算法/协议生成或评估测试向量覆盖度时，通过变异测试定位逃逸变异体，再针对性生成新向量并对比击杀率证明有效性。

适用场景

解决思路

1. Phase 1 发现实现：寻找目标算法的纯实现（Go/Rust/Python 等高层语言，最适合变异测试）、FFI 包装 crate（尽早识别以免浪费时间变异包装胶水代码）、参考实现（用于交叉验证但未必是最佳变异目标）；对每个实现记录语言与变异测试框架、是纯代码还是 FFI 包装、现有测试套件规模与覆盖率、测试向量将覆盖的 API 面。
2. 实现类型分类：纯实现变异价值高（如 zkcrypto/bls12_381、gnark-crypto）；FFI 绑定到 C/asm 在绑定层价值低（如 blst Rust crate）；C/C++ 实现价值高（用 Mull）；生成代码价值中等（变异可能是等价变异）。关键：若实现通过 FFI 委托到另一语言，必须变异底层实现而非绑定；Rust/Go/Python 底下的 C/C++ 用 Mull 等工具。
3. Phase 2 编写测试 harness：从 JSON 文件（推荐 Wycheproof 格式）读取测试向量；对每个向量调用实现 API；同时断言接受与拒绝（有效向量反序列化成功且输出匹配预期，无效向量反序列化失败或验证拒绝）；对有效反序列化向量加往返断言 serialize(deserialize(bytes)) == bytes；按向量报告通过/失败并带 test ID。只检查有效向量的 harness 会漏掉所有宽松变异（如校验中 & → |）。
4. harness 放置：必须位于被变异实现的包内，让变异框架能看到。Go 把 _test.go 放到同包；Rust 把集成测试放到 tests/ 或内联 #[test]；Python 放 pytest 测试文件；C/C++ 链接测试二进制。
5. 处理已有向量：先用仅现有向量跑变异测试（基线），再用仅新向量跑，再用两者合并跑；基线与合并的差值即新向量的价值。
6. Phase 3 基线：用现有测试向量跑变异测试。框架选择：Go 用 gremlins（gremlins unleash ./path/to/package），Rust 用 cargo-mutants（cargo mutants -j N --timeout T），Python 用 mutmut（mutmut run --paths-to-mutate src/），C/C++ 用 Mull（mull-runner -test-framework=GoogleTest binary）。
7. 并行执行：大代码库务必并行，如 cargo mutants -j 8、gremlins unleash --timeout-coefficient 3、mutmut run --runner "pytest -x -q"。
8. 记录基线指标：总变异体数、被击杀数、存活数（目标）、未覆盖数、超时数（有歧义，比较前先解决）、Efficacy % = Killed/(Killed+Survived)、Coverage % = (Total-Not covered)/Total；保存完整变异日志供 Phase 4 分析。
9. Phase 4 逃逸分析（图驱动分诊，必须使用 genotoxic 技能的分诊方法）：先用 Trailmark 构建调用图，Go 用 uv run trailmark analyze --language go --summary {targetDir}，Rust 用 uv run trailmark analyze --language rust --summary {targetDir}；图提供调用者链（从公共 API 入口追踪到被变异函数判断可达性）、圈复杂度（优先高 CC 函数）、爆炸半径（调用者多的函数影响更广）。
10. 过滤到相关代码：变异框架会测试整个包，需过滤到测试向量应覆盖的文件/函数。Go（gremlins）用 grep -E "(LIVED|NOT COVERED)" baseline.log | grep -E " at (relevant|files)" | sort；Rust（cargo-mutants）用 cat mutants.out/missed.txt | grep "src/relevant"。
11. 图驱动分类：对每个逃逸变异体映射到调用图中的所属函数并按 genotoxic 标准分类——图中无调用者=假阳性（死代码，跳过）；仅测试调用者=假阳性（测试基础设施）；日志/显示/格式化=假阳性（外观）；跨包调用者但 NOT COVERED=跨包缺口；从公共 API 可达且低 CC=缺失向量（设计针对性向量）；从公共 API 可达且高 CC(>10)=模糊测试目标（向量+模糊 harness）；校验/错误处理路径=负向向量（构造触发该路径的无效输入）；优化路径（GLV、SIMD、batch）=边界向量（触发优化阈值的输入）；左移后的 |→^（如 (t<<1) | carry）=等价变异（跳过，bit 0 恒为 0，OR=XOR）；Montgomery limb 上 ct_eq 的 &→|=API 不可达（需库内部测试而非向量）；行为不变的等价变异=假阳性（跳过）。
12. 识别跨包测试缺口：变异框架常只运行与变异同包的测试（Go gremlins、Rust cargo-mutants），如 hash_to_curve/g2.go 的变异只跑 hash_to_curve 包测试，不跑导入它的父 bls12381 包测试；被跨包测试充分覆盖的函数会显示为 NOT COVERED，属假阳性。确认方法：检查被变异函数是否被不同包的测试调用。解决：在子包加薄测试走与跨包测试相同代码路径，或用 gremlins --test-pkg ./...（若支持），或在报告中记录为框架限制。
13. 按安全影响排序存活变异体：P0 关键（削弱校验/相等性/认证，如 ct_eq 的 &→| 使相等性变宽松）；P1 高（反序列化标志解析，如 from_compressed 的 &→| 接受无效标志）；P2 中（域算术内部，如 Fp::square 的 |→^ 破坏计算）；P3 低（优化路径，如 phi 自同态只影响性能路径）；跳过（格式化、显示、等价变异，如 Debug::fmt 返回值替换）。
14. 按向量策略分组逃逸变异体：按代码路径与所需向量类型分组（如反序列化标志校验 P1 → 需有效点错误标志向量；域算术 P2 → 需边界值域算术 KAT；优化阈值 P3 → 需大标量标量乘法；跨包框架限制 → 记录为假阳性或加子包测试），每组成为 Phase 5 新向量目标。
15. Phase 5 向量生成：按代码路径类型设计向量——点反序列化用畸形点（错误长度、无效域元素、离曲线、错误子群、单位元）；签名验证用有效签名+对 sig/pk/msg 的所有单比特损坏；hash-to-curve 用边界输入 KAT（空、单字节、最大长度）；聚合操作用 1 签名者、多签名者、重复签名者、混合有效/无效；错误处理为每条错误路径构造触发向量；算术边界用零、一、域模数-1、无穷远点；序列化标志用每个有效标志组合+每个无效标志组合；往返完整性对每个有效反序列化向量断言 serialize(deserialize(b)) == b；进位/约简故障在缩减 limb 宽度下重实现、注入故障、提取区分性输入。
16. 单故障负向向量：每个负向向量应恰好有一个缺陷、其余全部有效，以隔离被测的校验检查。
17. 故障模拟（limb 宽度重实现）：当变异测试只做局部运算符替换时，深层架构 bug（进位传播、约简溢出）无法被测；在缩减 limb 宽度（8、16、25、32 位）下重实现目标算法并故意注入故障，再生成能捕获它们的向量。
18. 交叉实现验证：每个新测试向量在加入套件前必须对至少两个独立实现验证——用实现 A 生成，用实现 B（不同代码库、最好不同语言）验证；若 B 不一致则调查（其中一个实现有 bug）。
19. 向量格式：用 Wycheproof JSON 格式（algorithm、testGroups[].tests[] 含 tcId、comment、result、flags）。Wycheproof 贡献用其 vectorgen 工具而非直接格式化向量文件，以 envelope 形式提交生成的变更；vectorgen 可增/改/替换向量并处理 tcId 分配、测试计数、规范格式与 schema 校验；Go 生成器可绕过 vectorgen CLI 直接调用 github.com/c2sp/wycheproof/vectorgen 编程 API。
20. Phase 6 验证：把新向量纳入后重跑变异测试；向量开发期用按文件变异测试快速迭代，仅最终对比跑全 crate 测试。
21. 前后对比：记录 Killed、Survived、Not Covered、Efficacy % 的基线/新向量/差值（Survived 与 Not Covered 应下降）。
22. 成功标准：向量兼具回溯价值（击杀现有代码变异体）与前瞻价值（捕获未来实现 bug），两类都要生成——边界条件向量可能不提升成熟库击杀率但会捕获新实现 bug。回溯（可测量）：先前存活/未覆盖的变异体变为被击杀且无回归。若击杀率不变：实现自身测试可能已覆盖这些路径，向量仍提供交叉实现验证价值，记录属于哪种情况。
23. 输出：写 VECTOR_FORGE_REPORT.md，覆盖目标算法、测试的实现、基线结果、逃逸分析、生成的新向量、之后结果、前后差值、结论。
24. 交付前质量检查：至少一个纯实现被变异测试（不只是 FFI 包装）；用现有向量完成基线；为每个实现构建 Trailmark 调用图；用图驱动分类分诊所有逃逸变异体；识别并记录跨包假阳性；安全关键变异（ct_eq、校验、认证）优先为 P0/P1；故障模拟与变异派生向量对 2+ 实现交叉验证；纳入新向量后完成 after 运行；计算并解释前后差值；报告写入 VECTOR_FORGE_REPORT.md；新测试向量以标准格式（Wycheproof JSON）保存。

适用边界 · 注意事项

• 尚无任何实现存在（需要代码才能变异）
• 只有单个无边界情况的平凡实现
• 测试的是应用逻辑而非算法实现
• 算法没有可对比的公开测试向量