hashsigs-ts测试最佳实践RFC 8391测试向量80%覆盖率双保险3步守护密码库正确性【免费下载链接】hashsigs-tsHash-based signatures in typescript, WOTS项目地址: https://gitcode.com/gh_mirrors/ha/hashsigs-tshashsigs-ts是一个用 TypeScript 实现的基于哈希的数字签名库核心是后量子安全的 WOTSWinternitz One-Time Signature Plus算法。对密码学代码来说能跑通不等于跑得对——一个位翻转都可能导致签名验证结果错误。hashsigs-ts 的解法是给测试加双保险用 IETF 标准 RFC 8391 的官方测试向量做标准答案对照再设置 80% 的代码覆盖率硬门槛兜底。这篇文章带你拆解它的测试体系。为什么密码库测试需要特殊对待普通应用出 bug 顶多页面报错密码库出 bug 则是安全性归零签名验不过、或者更糟——假签名被验证通过。所以密码库测试要回答两个问题我的实现和标准一致吗→ 用权威测试向量Test Vectors对照我的测试真的覆盖了核心逻辑吗→ 用代码覆盖率Coverage量化hashsigs-ts 恰好把这两件事都做成了工程化的固定流程。测试工具链Vitest V8 覆盖率项目选用 Vitest覆盖率引擎使用 V8 引擎provider: v8对 TypeScript 零额外配置开启all: true未被任何测试 import 的文件也会计入统计防止漏测文件钻空子排除规则干净利落node_modules、dist、.d.ts声明文件、coverage目录本身都不参与统计同时输出 5 种格式报告text控制台、text-summary、json、html、lcov方便接入 CI/CD 流水线配套的 npm 脚本定义在 package.json 中命令作用npm test跑一次全部测试npm run test:watch开发时热更新跑测试npm run coverage跑测试并生成覆盖率报告核心武器RFC 8391 测试向量文件最有价值的一个文件是 test/test_vectors/wotsplus_keccak256.json。它包含5 组官方测试向量vector0 ~ vector4每组都是一套完整的已知输入 已知正确结果私钥、公钥各分段、消息、公钥种子publicSeed、随机化元素、签名值——全部以十六进制串记录。这类向量来自 XMSS 标准规范 RFC 8391WOTS 是其定义的 WOTS 层算法wotsplus.ts 中的prf、随机化元素生成等注释也明确标注对齐了 RFC 8391 第 5.1 节。它相当于标准给出的标准答案只要实现与标准一致用自己的实现去验证这些向量结果必须全部通过。这比自己签名、自己验证强得多——自签自验的测试可能只是把同样的错误实现了两遍而独立测试向量能抓出这类自我一致的 bug。测试用例设计7类场景层层设防打开 src/wotsplus.test.ts可以看到 7 组测试用例设计思路很有代表性#用例验证目标1生成密钥对公钥/私钥长度正确私钥非零2拒绝空签名异常路径全零签名必须验证失败3验证自签名正常路径签名后立即验证通过4随机化元素验证复用 RFC 8391 风格的 PRF 路径verifyWithRandomizationElements5批量签名循环多组密钥对 不同消息的稳定性6批量随机化验证同上走带随机化元素的验证入口7JSON 测试向量逐条跑 5 组 RFC 8391 向量双入口各验一次几个值得新手学习的设计细节异常路径也测用例 2 特意构造全零签名断言验证必须失败。密码库里什么情况下会拒绝和什么情况下会通过同等重要。两个验证入口都测verify与verifyWithRandomizationElements是面向不同调用场景的等价路径测试向量对两个入口各跑一遍见 wotsplus.test.ts 第 177~188 行保证两条路径行为一致。断言失败信息带向量名expect(isValid, Standard verification failed for ${vectorName})一旦某条向量挂掉报错直接告诉你是哪条定位成本低。80% 覆盖率门槛让测够了变成硬约束README.md 中明确写死了三项最低覆盖率标准函数Functions80%分支Branches80%语句Statements80%并且要求提交 PR 前必须所有测试通过、覆盖率达标。这把测试写没写够从主观判断变成了客观门槛——没有测试覆盖的代码在合并前就会被 CI 拦下。查看覆盖率的步骤很简单运行npm run coverage控制台直接看汇总表需要细看时打开./coverage/index.html的 HTML 报告未覆盖的行会高亮标出如果接了 CI/CDlcov 报告可以直接上传到代码托管平台的覆盖率插件快速上手3步复现完整测试流程# 1. 克隆仓库 git clone https://gitcode.com/gh_mirrors/ha/hashsigs-ts # 2. 安装依赖 npm install # 3. 运行测试与覆盖率 npm run coverage跑完后重点关注两件事7 组用例是否全部通过覆盖率三个指标是否都 ≥ 80%。总结可复用的3条密码库测试最佳实践hashsigs-ts 的测试体系浓缩成 3 条可迁移的经验✅用权威标准测试向量做标准答案——比自签自验更可靠能抓出自我一致的 bug✅正常路径 异常路径 等价入口都要覆盖——密码库尤其要测正确拒绝✅给覆盖率设硬性门槛如 80%并写入 CI——让测试完备度成为可量化的合并条件附相关文件索引核心实现src/wotsplus.tsWOTS 类生成密钥、签名、验证测试用例src/wotsplus.test.tsRFC 8391 测试向量test/test_vectors/wotsplus_keccak256.json覆盖率配置vitest.config.ts构建入口导出src/index.ts【免费下载链接】hashsigs-tsHash-based signatures in typescript, WOTS项目地址: https://gitcode.com/gh_mirrors/ha/hashsigs-ts创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
hashsigs-ts测试最佳实践：RFC 8391测试向量+80%覆盖率双保险，3步守护密码库正确性
hashsigs-ts测试最佳实践RFC 8391测试向量80%覆盖率双保险3步守护密码库正确性【免费下载链接】hashsigs-tsHash-based signatures in typescript, WOTS项目地址: https://gitcode.com/gh_mirrors/ha/hashsigs-tshashsigs-ts是一个用 TypeScript 实现的基于哈希的数字签名库核心是后量子安全的 WOTSWinternitz One-Time Signature Plus算法。对密码学代码来说能跑通不等于跑得对——一个位翻转都可能导致签名验证结果错误。hashsigs-ts 的解法是给测试加双保险用 IETF 标准 RFC 8391 的官方测试向量做标准答案对照再设置 80% 的代码覆盖率硬门槛兜底。这篇文章带你拆解它的测试体系。为什么密码库测试需要特殊对待普通应用出 bug 顶多页面报错密码库出 bug 则是安全性归零签名验不过、或者更糟——假签名被验证通过。所以密码库测试要回答两个问题我的实现和标准一致吗→ 用权威测试向量Test Vectors对照我的测试真的覆盖了核心逻辑吗→ 用代码覆盖率Coverage量化hashsigs-ts 恰好把这两件事都做成了工程化的固定流程。测试工具链Vitest V8 覆盖率项目选用 Vitest覆盖率引擎使用 V8 引擎provider: v8对 TypeScript 零额外配置开启all: true未被任何测试 import 的文件也会计入统计防止漏测文件钻空子排除规则干净利落node_modules、dist、.d.ts声明文件、coverage目录本身都不参与统计同时输出 5 种格式报告text控制台、text-summary、json、html、lcov方便接入 CI/CD 流水线配套的 npm 脚本定义在 package.json 中命令作用npm test跑一次全部测试npm run test:watch开发时热更新跑测试npm run coverage跑测试并生成覆盖率报告核心武器RFC 8391 测试向量文件最有价值的一个文件是 test/test_vectors/wotsplus_keccak256.json。它包含5 组官方测试向量vector0 ~ vector4每组都是一套完整的已知输入 已知正确结果私钥、公钥各分段、消息、公钥种子publicSeed、随机化元素、签名值——全部以十六进制串记录。这类向量来自 XMSS 标准规范 RFC 8391WOTS 是其定义的 WOTS 层算法wotsplus.ts 中的prf、随机化元素生成等注释也明确标注对齐了 RFC 8391 第 5.1 节。它相当于标准给出的标准答案只要实现与标准一致用自己的实现去验证这些向量结果必须全部通过。这比自己签名、自己验证强得多——自签自验的测试可能只是把同样的错误实现了两遍而独立测试向量能抓出这类自我一致的 bug。测试用例设计7类场景层层设防打开 src/wotsplus.test.ts可以看到 7 组测试用例设计思路很有代表性#用例验证目标1生成密钥对公钥/私钥长度正确私钥非零2拒绝空签名异常路径全零签名必须验证失败3验证自签名正常路径签名后立即验证通过4随机化元素验证复用 RFC 8391 风格的 PRF 路径verifyWithRandomizationElements5批量签名循环多组密钥对 不同消息的稳定性6批量随机化验证同上走带随机化元素的验证入口7JSON 测试向量逐条跑 5 组 RFC 8391 向量双入口各验一次几个值得新手学习的设计细节异常路径也测用例 2 特意构造全零签名断言验证必须失败。密码库里什么情况下会拒绝和什么情况下会通过同等重要。两个验证入口都测verify与verifyWithRandomizationElements是面向不同调用场景的等价路径测试向量对两个入口各跑一遍见 wotsplus.test.ts 第 177~188 行保证两条路径行为一致。断言失败信息带向量名expect(isValid, Standard verification failed for ${vectorName})一旦某条向量挂掉报错直接告诉你是哪条定位成本低。80% 覆盖率门槛让测够了变成硬约束README.md 中明确写死了三项最低覆盖率标准函数Functions80%分支Branches80%语句Statements80%并且要求提交 PR 前必须所有测试通过、覆盖率达标。这把测试写没写够从主观判断变成了客观门槛——没有测试覆盖的代码在合并前就会被 CI 拦下。查看覆盖率的步骤很简单运行npm run coverage控制台直接看汇总表需要细看时打开./coverage/index.html的 HTML 报告未覆盖的行会高亮标出如果接了 CI/CDlcov 报告可以直接上传到代码托管平台的覆盖率插件快速上手3步复现完整测试流程# 1. 克隆仓库 git clone https://gitcode.com/gh_mirrors/ha/hashsigs-ts # 2. 安装依赖 npm install # 3. 运行测试与覆盖率 npm run coverage跑完后重点关注两件事7 组用例是否全部通过覆盖率三个指标是否都 ≥ 80%。总结可复用的3条密码库测试最佳实践hashsigs-ts 的测试体系浓缩成 3 条可迁移的经验✅用权威标准测试向量做标准答案——比自签自验更可靠能抓出自我一致的 bug✅正常路径 异常路径 等价入口都要覆盖——密码库尤其要测正确拒绝✅给覆盖率设硬性门槛如 80%并写入 CI——让测试完备度成为可量化的合并条件附相关文件索引核心实现src/wotsplus.tsWOTS 类生成密钥、签名、验证测试用例src/wotsplus.test.tsRFC 8391 测试向量test/test_vectors/wotsplus_keccak256.json覆盖率配置vitest.config.ts构建入口导出src/index.ts【免费下载链接】hashsigs-tsHash-based signatures in typescript, WOTS项目地址: https://gitcode.com/gh_mirrors/ha/hashsigs-ts创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
