题干与适用场景
请实现一个 ML-DSA 签名验证封装：调用方提供算法、公开密钥、消息、签名和上下文。你会如何校验输入、避免跨协议重放，并设计错误处理与测试？
面试官考察点
- 是否复用经过验证的 FIPS 204 实现，而不是自行重写格密码原语。
- 是否把算法标识、公开密钥、消息、签名和 context 作为不可混淆的输入。
- 是否区分签名无效、输入格式错误、算法不支持和内部故障，避免泄露敏感细节。
- 是否通过上下文绑定、固定接口和向量测试防止跨协议重放与实现漂移。
回答前需要澄清的问题
- 使用 ML-DSA 的哪种参数集，库是否经过 FIPS 204 向量验证？
- context 由哪个协议定义，是否允许为空，编码和长度限制是什么？
- 验证失败是普通业务结果，还是需要触发告警与审计？
- 消息是否流式、是否需要预哈希接口，以及密钥轮换如何处理？
30 秒回答框架
我会把封装限制在已验证的 ML-DSA 库 API。先根据显式算法标识选择参数集，严格校验字节输入和 context，再把 protocol context 与消息一起交给库验证。返回值只区分 valid、invalid、unsupported 和 malformed，不把异常堆栈返回给调用方。测试覆盖官方向量、篡改、错误参数集、跨 context 重放、边界长度、并发和密钥轮换；私钥和完整消息不进日志。
分步骤深入解答
1. 设定封装边界
FIPS 204 规定 ML-DSA 的签名生成和验证算法；RFC 9882 说明 CMS 使用时，hedged 与 deterministic 签名使用相同验证算法。业务代码不应实现 NTT、采样或拒绝采样，而应固定依赖版本、参数集和经过测试的库接口。
2. 做输入与上下文校验
接口先检查算法标识是否允许、公开密钥和签名字节是否符合所选参数集、消息是否处于允许大小，并按协议规范编码 context。context 不是日志标签，它参与签名域分离；验证时必须使用签名生成方约定的同一值。缺失或错误 context 直接返回 malformed/invalid，不能自动尝试空 context。
3. 设计安全错误语义
对外返回结构化结果，例如 valid、invalid、unsupported、malformed，避免把库异常、密钥内容或解析细节回显。统计和审计只记录算法、版本、结果类别与 request id。内部异常要进入受控错误通道并触发告警，不能把“库崩溃”伪装成签名无效。
4. 用向量和协议测试锁定行为
先跑 NIST ACVP 或 FIPS 204 兼容向量，再测试一位篡改、截断、拼接不同 context、错误算法标识和旧密钥。验证跨协议场景时，确保同一消息在不同 context 下不会被接受。并发调用使用不可变输入，密钥轮换同时接受明确的旧版本窗口，过期后拒绝。
高质量示范回答
我会把实现限制为已验证库的薄封装，不重写 ML-DSA 原语。调用方必须显式提供算法标识、参数集、公开密钥、消息、签名和协议 context；封装先校验格式与大小，再把同一个 context 传给验证 API，绝不在失败时自动尝试其他参数集或空 context。对外只返回 valid、invalid、unsupported、malformed 四类结果，内部异常单独告警，日志不含私钥和消息。用 FIPS/ACVP 向量、篡改、截断、跨 context 重放、密钥轮换和并发测试锁定行为，并固定库版本与参数配置。
常见错误
- 自己实现 ML-DSA 的 NTT、采样或拒绝采样。
- 忽略算法标识，让同一公钥在不同参数集间尝试验证。
- 验证失败时自动重试空 context 或其他 context。
- 把库异常、签名无效和输入格式错误混成一个无依据的成功/失败。
- 将完整消息、密钥或异常堆栈写入日志。
- 只写 happy path，没有官方向量、篡改、重放和轮换测试。
追问及应对
hedged 和 deterministic 签名需要不同验证代码吗？
不需要。RFC 9882 明确指出两种签名使用相同的验证算法；封装不应根据签名模式选择两套验证路径。
为什么 context 能防跨协议重放？
它把签名绑定到协议域。相同消息和密钥在不同 context 下应产生不同的验证语义；验证器不能在 context 缺失时猜测或回退。
如何处理库升级？
锁定参数集和库版本，先用官方向量与历史兼容样本做回归，再小比例切换。记录版本和结果类别，发现差异时保留旧验证路径直到完成迁移。