📚 课程目录第2章密码算法正确性验证基础

2. 密码算法正确性验证基础

密码算法的正确性验证，核心目标不是评估算法“安全不安全”，而是确认一个具体实现是否严格符合标准定义。同一套 AES 或 SM2 算法，不同厂商、不同语言、不同硬件加速路径的实现可能在绝大多数输入下结果一致，却在某个边界输入上产生偏差。已知答案测试（Known Answer Test, KAT）正是用标准给定的输入—输出对来锁定这种偏差。

五类算法的验证对象与测试向量形态

对称加密、公钥加密、杂凑、消息认证码、数字签名这五类原语，其标准测试向量的构造方式差异很大，验证时必须分别对待。

对称加密（如 AES、SM4）的测试向量通常由密钥、明文、工作模式、初始向量/计数器、密文五元组构成。以 AES-128-ECB 为例，NIST SP 800-38A 给出的向量为：密钥 2b7e151628aed2a6abf7158809cf4f3c，明文块 6bc1bee22e409f96e93d7e117393172a，对应密文 3ad77bb40d7a3660a89ecaf32466ef97。验证时不仅要核对最终密文，还应核对解密回明文是否一致，形成双向闭环。

公钥加密（如 RSA-OAEP、SM2）的向量必须固定填充方案和随机源。RSA-OAEP 的加密结果依赖随机种子，因此标准向量通常给出固定种子下的密文，或直接验证解密路径：给定密文和私钥，检查解密结果是否等于预期明文。SM2 加密同样需要固定随机数 k，否则密文每次不同。

杂凑（如 SHA-256、SM3）的向量最简单：消息与摘要二元组。SM3 对空串的摘要为 1ab21d8355cfa17f8e61194831e81a8f22bec8c728fefb747ed035eb5082aa2b，对 abc 的摘要为 66c7f0f462eeedd9d1f2d46bdc10e4e24167c4875cf2f7a2297da02b8f4ba8e0。这类向量适合做快速冒烟测试。

消息认证码（HMAC、CMAC、GMAC）的向量需要同时固定密钥、消息、算法和输出长度。HMAC-SHA256 在 RFC 4231 中给出了多组用例，包括密钥长度等于、小于、大于分组长度的情况，这正是边界测试的典型设计。

数字签名（RSA-PSS、ECDSA、SM2 签名）的验证分为签名生成和签名验证两个方向。由于签名依赖随机数或确定性 k，标准向量通常提供私钥、消息、签名值，验证方用公钥验签应返回成功；同时用篡改后的消息验签应返回失败。

边界条件的设计方法

标准向量覆盖的是“典型正确路径”，而边界条件才是实现缺陷的高发区。设计边界用例时，应围绕算法规范中明确规定的长度、范围和特殊值展开。

对于分组密码，重点包括：明文长度恰好为分组整数倍、比分组整数倍多 1 字节、少 1 字节；密钥长度取允许的最小值和最大值；IV 或计数器取全零、全 F、以及即将溢出的值。对于杂凑和 MAC，重点包括：空消息、单字节消息、恰好等于分组长度的消息、比分组长度多 1 字节的消息。RFC 4231 中 HMAC-SHA256 的测试用例 1 到 7 就系统覆盖了密钥长度小于、等于、大于分组长度，以及消息为空和超长的情况。

对于公钥算法，边界条件更多体现在参数域上：RSA 模数的最小允许位数、明文消息接近模数上限、OAEP 填充后恰好等于模长；SM2 签名中随机数 k 取 1 或 n-1；ECDSA 中临时公钥的 x 坐标回绕。这些用例往往能暴露模幂运算、模逆运算或点乘实现中的进位和约减错误。

已知答案测试的执行与判读

KAT 的执行流程可以概括为：加载向量集 → 逐条调用被测实现 → 将输出与期望值做逐字节比较 → 记录通过/失败 → 对失败项定位参数。关键在于比较必须是逐字节的，不能只比较长度或哈希后的结果，否则会掩盖单比特错误。

一个实用的做法是把向量组织为结构化数据，每条记录包含算法标识、参数集、输入字段和期望输出字段。下面是一个简化的测试用例表结构示例：

{
  "algorithm": "SM4",
  "mode": "ECB",
  "key": "0123456789abcdeffedcba9876543210",
  "plaintext": "0123456789abcdeffedcba9876543210",
  "expected_ciphertext": "681edf34d206965e86b3e94f536e4246",
  "source": "GM/T 0002-2012 附录A"
}

执行时，若密文不匹配，应进一步检查：密钥是否被正确解析为字节序、明文是否按分组对齐、是否误用了填充。若解密回明文不匹配但加密密文匹配，则问题可能出在解密路径的密钥调度或逆变换上。

判读要点：KAT 失败不一定意味着算法实现完全错误，也可能是测试框架的字节序、编码方式或参数传递有误。定位时应先确认向量加载和参数映射无误，再怀疑算法实现本身。

验证结果的可信度边界

需要清醒认识的是，KAT 通过只说明实现在这些特定输入上正确，不能证明在所有输入上都正确，更不能证明实现是安全的。侧信道泄漏、故障注入、随机数质量等问题不在 KAT 的覆盖范围内。因此，KAT 应作为正确性验证的第一道门槛，与差分测试、统计测试、侧信道评估配合使用，才能形成完整的验证链条。

在实际工程中，建议将标准向量集固化为回归测试套件，每次代码变更后自动执行。对于国密算法，应优先采用 GM/T 0002、GM/T 0003 等标准附录中的向量；对于国际算法，NIST CAVP 和 RFC 系列是权威来源。向量的来源必须可追溯，避免使用来源不明的“网传向量”导致误判。