国密算法都对，报文为什么验不过

结论先行：国密改造走到联调这一步，最常出现的僵局是「两家都合规、验签就是过不了」。卡点多数不在算法运算，而在报文封装这一层——签名值怎么编码、用户标识怎么约定、摘要算法有没有在报文里声明。这些过去属于实现细节，只能靠联调硬磨；自 2026 年 11 月 1 日起，封装格式有了统一标准，实现偏差本身就成了有据可查的问题。

本文只谈报文封装与跨厂商联调的卡点怎么排、怎么对，不谈操作系统侧的内生安全体系怎么建，也不谈加密算法本身的迁移路线。

卡点不在算法，在信封

国密体系是一套分工清晰的组合：算法本体定义在一份标准里，使用规范在另一份，数字证书格式在第三份。这三层各自成熟，也各自有对应的测评口径。而「一份签名或一次加密的结果，如何封装、如何标识、接收方如何解析」，属于另立一层的封装规范。

这一层过去恰恰是国密改造里最缺统一口径的地带。项目上碰到的典型场景是这样的：一方生成签名报文，另一方的密码机验不过；两边各自拿算法向量自测，都通过；把报文字节逐个比对，才发现差异出在几个不起眼的地方。

这三处的共同点是：都不影响算法自身正确性，也都不会被算法向量测出来。它们只在两个实现对接的那一刻暴露，而那一刻通常已经排进了上线计划。

新版标准动了哪三处，需要改代码

2026 年 11 月 1 日起实施的国密消息格式标准，全部代替 2017 年的旧版。它改的不是算法，而是封装规则。整份标准共有八处技术变化，其中大部分属于文档与定义层面的梳理，真正需要动代码的集中在三处。

值得留意的是新增的两种类型。摘要数据类型解决的场景是「只要证明内容没被改，不需要暴露签名者身份」；鉴别数字信封则在传统数字信封之上叠加完整性校验，密文一旦被改动即解密失败，一次同时提供机密性与完整性。过去没有独立类型，厂商各自约定封装方式，两套系统各自跑得通，一对接就露馅。

过渡期里新旧并存，排期怎么排

标准实施不等于全网当天切完。存量系统、第三方组件、密码设备固件各有自己的升级节奏，过渡期内新旧格式必然并存一段时间。可行的排法是把升级拆成三段，而不是一次性替换。

其一，先盘清谁在生成、谁在验

把参与国密通信的组件列出来，逐个标注它当前是「只生成」「只验签」还是「两者都做」。只做一侧的组件升级风险最低，两侧都做且跨厂商对接的，才是重点。这份清单本身就要能回答：哪些对接组合是跨厂商的、当前跑的是哪种封装。

其二，让新旧能被识别

版本号统一之后，接收方可以按版本分别解析。这时不要急着要求所有对端同时升级，而应当先让自己的接收侧具备双版本解析能力——先能读懂两套，再决定什么时候只讲一套。顺序反过来，就会出现「我升了，对端读不了」的单点中断。

其三，把跨厂商那一组留到最后

同一厂商内部的组件升级，封装口径天然一致，风险主要在自己的回归测试。而跨厂商那一组，升级窗口需要双方对齐，还要预留排查时间。这一组应当排在整体计划的末段，并且配一个能快速回到旧格式的开关。

联调前可以先做的四件事

• 把参与对接的每一组，标注算法、证书格式、封装格式三项的实际取值，不用「都支持国密」这一句概括。
• 准备一组带边界值的测试向量：空内容、超长内容、中文标识、不同摘要算法各一条，专门用来暴露封装差异。
• 要求对端提供一份「我们按哪个版本封装、签名值怎么编码」的书面说明，而不是在联调现场口头确认。
• 在变更单里写明回退方式：回到旧格式需要改哪几个配置、耗时多久、由谁执行。

边界与前提

三点说明。其一，本文关于标准版本、实施日期与技术变化的描述，取自公开发布的标准文本说明与行业报道，具体条款以标准原文为准；不同行业与系统的适用范围，应以主管部门要求为据。其二，国密改造的合规判定涉及算法、密钥、证书与封装多个层面，本文只覆盖封装这一层，其余层面不在讨论范围。其三，文中不涉及任何具体厂商的实现细节与产品名称，实际联调结论以本项目实测为准。

深圳市奇摩计算机有限公司做的是服务这一端。这类联调我们通常不放在上线前那几天，而是先在实验环境里把跨厂商那几组跑一遍，把封装差异提前暴露出来。预约咨询，可以先从「列出每一组的封装取值」这张表开始。