验签内部算对了，API却把所有签名都判成有效

密码安全 / 真实异常信号 · 9.0/10 · 建议深挖

ngcc.dev正在独立测试中国下一代商用密码算法竞赛的候选提交。先说明身份：这个网站明确表示与竞赛组织方NICCS没有隶属关系，由坦佩雷大学研究者Markku-Juhani Saarinen维护。它的价值不在“官方盖章”，而在于固定被测归档的哈希、公开完整报告、复现命令和统一测试harness。

最直观的例子来自签名候选UVW，编号sign-32。内部uvw_verify会正常计算签名是否有效，API包装器也把结果转换成0或-1并存进局部变量，最后却无条件return 0。在这套API里，0表示成功。于是无效签名、被修改的消息和任意正确长度的字节串，都被三个参数集报告为有效。

这不是高深的密码分析，而是一个返回值错误，却直接造成通用伪造。报告还发现，正确长度的全零签名会让UVW-128和UVW-256在解析时崩溃；UVW-512没有复现这一崩溃，因此没有被算进第二项问题。报告把前者标为Critical / implementation / Confirmed，后者标为High / implementation / Confirmed，并给出复现命令。

Aigis-Sig+的边界更适合说明“严重”并不等于所有安全性质一起失效。它的非规范hint编码允许攻击者把一条有效签名改成同一消息上的另一条有效签名，破坏强不可伪造性SUF-CMA，但这本身不等于可以给新消息造签名。另一处解析缺少计数、长度和位置检查，会在验证未经认证的签名时触发攻击者控制的栈写入。未授权拒绝服务已经确认，更强的利用效果取决于平台。

两个案例都指向提交的参考实现和API，不能自动推导为底层密码设计已经失效，更不能拿来概括整个NGCC候选集。索引中的No report也只表示该站还没有报告，不是安全证明；Lead、Probable和Proof gap同样不能写成已经完成的攻击。截止本期检索，我们没有在公开报告、站点源码和harness里找到UVW或Aigis-Sig+提交团队的公开回应或修复版本，这一项仍需继续跟踪。

这组报告留下的教训很朴素：密码方案从论文走到代码，真正交付的是整个验证链。边界检查、反例测试和API返回值没有做好，前面再漂亮的数学证明也救不了最后一行代码。