ARTICLE · 1228539
当国密改造遇上AI
商用密码 · 密评 · 大模型落地
国密改造遇上 AI
降本空间是真的，但那 6 个坑也是真的
一个中等规模的业务系统，把密码应用改造的待办清单列到 800 多条，并不稀奇。
SM2 换 RSA、SM4 换 AES、SM3 换 MD5，听起来只是“换个库、改个 API”。真做起来，八成时间花在三件事上：找、改、证。
AI 恰好能压缩这三件事。但它也能在你最不该省的地方，帮你省出一个事故。
适合谁读
架构师 / 技术负责人安全合规负责人密码改造项目经理
如果你正在拆解改造工作量、评估 AI 到底能用到哪一步、或者准备迎接密评——这篇可以直接当内部讨论的底稿。
PART 01 结论
先给结论，懒得看全文的直接抄
看点：成本大头不在算法，在“发现”和“证明”。
1国密改造的成本大头不在算法，在发现和证明。算法替换本身是机械劳动，而机械劳动正好是 AI 的主场。
2AI 最值钱的三个位置：代码侧算法测绘、影响面（字段 / 协议 / 长度）分析、密评差距对照。共同点是“读得多、判断浅”。
3最不该交给 AI 的四件事：密钥管理决策、合规结论、证据链、密码正确性的最终验收。
4一个常被忽略的反向命题：你要用 AI 做国密改造，那这个 AI 系统自己也得过密评。
5如果方案是把生产代码直接贴进公有云大模型，这方案从第一天就不成立。
如果只记一句：AI 负责把“不知道有多少”变成“清单”，人负责把“清单”变成“可以签字的东西”。
PART 02 成本结构
国密改造到底贵在哪
看点：三块成本，一块比一块难压。
把成本拆开看，其实是三块：
发现成本通常占比最高
加密调用散落在几十个服务、几百个仓库、上千个文件里。Java 的 Cipher.getInstance("AES/CBC/PKCS5Padding")、Python 的 hashlib.md5()、Go 的 rsa.EncryptPKCS1v15、前端的 CryptoJS、运维脚本里的 openssl。正则能捞到一半；捞不到的是被封了三层的工具类、配置化的算法名、以及第三方 SDK 的内部实现。
迁移成本
不是换个算法名。分组模式、填充方式、IV 生成、编码、密钥派生，任何一处不一致，结果就是“改完能编译、能启动、数据读不出来”。这类问题往往要到联调甚至上线后才暴露。
证明成本几乎压不动
密评要的是证据链——配置截图、密钥管理制度、操作日志、测试报告、方案说明。这块只能提前组织。很多项目返工不是因为改错了，而是因为方案评估阶段没做，证据补不上。
国密改造里最贵的不是密码学，是工程量；工程量里最贵的不是写代码，是找到该写的代码。
PART 03 分工
AI 真正能接手的 6 个环节
看点：每一项都标了“AI 做”和“人验”，可以直接当分工表用。
不是“AI 帮你写代码”这种笼统的说法。逐项拆开，才看得出哪里能省、哪里要盯着。
AI 做
跨语言识别加密调用点，输出「文件:行号 + 算法 + 业务用途 + 是否涉及密钥」四元组。
人 验
抽检 20%，重点看封装层和动态调用。
AI 做
判断哪些字段是密文、替换后长度怎么变、哪些索引 / 唯一约束 / 协议字段会被撑破。
人 验
拿下一节的长度速查表逐行核对，这是最容易出事的地方。
AI 做
AES→SM4、RSA→SM2、MD5→SM3 的多语言改写，附带单元测试。
人 验
必须过标准测试向量 + 新旧双跑对拍。
AI 做
挂 RAG 读 GB/T 39786、GM/T 系列，把系统现状逐条对到要求上，出差距清单。
人 验
条款原文必须回查，AI 编条款号是常态。
AI 做
生成测试向量用例、双跑对拍脚本、边界与异常用例。
人 验
向量值本身要来自标准文本，不能由模型生成。
AI 做
密码管理制度、密钥生命周期规程、改造方案说明、应急预案初稿。
人 验
必须与本系统实际架构一致，不能是模板空话。
六项里，②最值钱，也最容易被低估。国密替换真正会炸的地方，往往不是算法算错了，而是长度变了——数据库字段装不下、定长校验失败、唯一索引截断、协议头预留不够。
下面这张速查表建议直接贴到项目群里：让 AI 按它输出影响面，人工逐行签字确认。
附：7 类常见替换的长度变化速查
标签含义：长度不变 / 变长 / 变短 / 非定长 / 结构变化
AES-128 / AES-256 → SM4长度不变
长度 分组同为 128 位，密文长度一般不变。
坑 填充方式、IV 处理必须一致；GCM 标签长度要对齐。
RSA-2048 加密 → SM2 加密变短
长度 定长 256 字节 → 约 97 字节 + 明文长度。
坑 密文可能变短，定长校验和补位逻辑会崩；长明文要改混合加密。
RSA / ECDSA 签名 → SM2 签名非定长
长度 签名值 64 字节，DER 编码后 70~72 字节，非定长。
坑 字段与协议头预留长度不够，Base64 后波动更大。
MD5 → SM3翻倍
长度 16 字节 → 32 字节，翻倍。
坑 摘要字段、Token、唯一索引必须扩容，否则截断后校验恒失败。
SHA-256 → SM3长度不变
长度 32 字节 → 32 字节，不变。
坑 最平滑的一类替换，建议优先改，先建立信心。
3DES / DES → SM4分组变化
长度 分组由 64 位变为 128 位。
坑 历史 ECB 数据不能原地换算法，必须解密后重新加密。
TLS 传输 → TLCP（GB/T 38636）结构变化
长度 双证书：签名证书 + 加密证书。
坑 客户端信任库、移动端 SDK、国密网关、IoT 固件要一起动。
注：SM2 密文按 C1‖C3‖C2 顺序、C1 取未压缩点估算，不同实现与编码方式会有差异，实际以所选密码库为准。
PART 04 边界
AI 干不了的 4 件事
看点：这四条不是能力问题，是责任问题。
1 密钥管理
密钥分层、生命周期、HSM / KMC 选型、密钥不落地、双人双控。密评最看重这一块，而它天然是“责任”问题，不是“生成”问题。AI 可以帮你写规程，但不能替你决定谁能持有密钥。
2 合规结论
密评由具备资质的商用密码检测机构实施，结论是符合 / 基本符合 / 不符合。AI 能帮你把材料备齐，不能替你签这个字。
3 证据链
不能生成日志、不能伪造截图、不能编测试报告。这是唯一一条没有灰度地带的红线——用 AI 造证据，性质就变了。
4 正确性验收
密码实现的正确性只认标准测试向量和双跑对拍。模型说“这段逻辑没问题”没有任何意义，它自己也不知道 SM2 的 C1C3C2 和 C1C2C3 该按哪个来。
关于幻觉
幻觉在密码领域代价特别高。编造标准条款号、编造 SDK 参数名、把 SM2 密文段顺序说反，都是常见输出。对策只有三条——RAG 挂原文、强制给引用、人工抽检。
PART 05 反向命题
你的 AI 系统自己也要过密评
看点：这一节最容易被漏掉，也最容易被问住。
很多团队在做两件事：给业务系统做国密改造，同时上线内部大模型应用。但很少有人意识到，第二个系统也要走一遍同样的流程，而且它的密码应用面比传统系统更宽。
传输Prompt、上传文档、检索结果全程加密，走 TLCP，不要只靠 HTTPS 裸奔。
存储知识库原文、向量库、会话日志都要加密。注意：embedding 仍是敏感数据的变形，不能当“已脱敏”处理。
完整性模型权重、配置文件用 SM3 摘要 + SM2 签名防篡改，防止加载被替换的模型。
身份调用方用 SM2 证书做双向认证，不要用裸 API Key 长期有效。
密钥由 KMS / HSM 托管，配置文件里不能出现明文密钥。
出域训练与推理数据的去向要说得清楚，这一条在密评和审计里都会被追问。
现在大多数团队的这部分是空白，而它偏偏是“应用和数据安全”层面最容易被问住的地方。
PART 06 节奏
一个可复用的落地节奏
看点：四个阶段，每个阶段都有明确产出物和验收口径。
P0 测绘2~4 周
把“不知道有多少”变成“知道有多少”
AI 全量代码扫描 + 语义归类，人工抽检 20%
产出 现状清单、算法分布热力图、高风险 Top20
P1 试点4~6 周
跑通一条完整链路，形成 SOP
AI 单系统代码迁移 + 测试向量 + 双跑对拍
产出 改造样板、迁移 SOP、长度影响清单
P2 批量按系统数量排期
流水线化：AI 出初稿，人做 review
节奏 一个改造单元走一遍 P1 的 SOP，不合格不进入下一个
产出 改造工单、回归报告、灰度切换记录
P3 密评2~3 个月
证据链归集与整改闭环
AI 对照标准生成自查表、汇总证据，不生成证据
产出 差距分析、整改台账、密评报告
一句话提醒：P3 不要等到最后才启动。方案评估缺失导致的返工，通常比代码迁移本身更贵。
PART 07 清单
踩坑清单，建议收藏
看点：9 条按领域标注，方便按类排查。
1密钥只换算法，不动密钥管理。密评第一关就卡这里。
2数据字段长度没扩容：MD5→SM3 翻倍，唯一索引和 Token 长度一起崩。
3数据定长密文字段遇上 SM2：RSA-2048 的 256 字节定长，换成变长后校验逻辑失效。
4数据历史数据不可逆：必须先设计“双算法共存期”——新写 SM4，老数据读时解密再加密，灰度切换。
5范围只改应用层：数据库 TDE、备份文件、日志、消息队列、缓存里的密文全被漏掉。
6协议忘了信任链：国密证书默认不在主流系统信任库里，网关、浏览器、移动端 SDK、IoT 固件要同步改。
7AI把生产代码和密钥配置贴进公有云大模型——等于把合规问题换成了泄露问题。
8AIAI 生成的密码代码没过测试向量就上线。看起来对，和真的对，是两件事。
9协议协议层被低估：TLCP 双证书、报文长度、握手兼容，往往比应用层代码更难改。
上线前自检三问
01 所有涉及密文和摘要的字段，长度是否已经按“最坏情况”扩容？
02 新旧实现有没有跑过标准测试向量和双跑对拍，结果是否归档？
03 密钥现在实际存在哪里、谁能取到、有没有留痕？说得清才算过。
国密改造是一场“确定性”的工程：标准明确、路径清楚、验收有据。
AI 在这类工程里能做的事，比你想象的少一点——它不懂密码学责任；也比你想象的多很多——它能读完你读不完的代码。
真正的分界线只有一条：可验证的交给 AI，需负责的留给人。
