国密改造 · 性能评估

一、先说结论：损耗多大，看用在哪

先给一颗定心丸：绝大多数管理类系统（表单、流程、报表、附件）做完国密改造，使用者感知不到性能变化。这类系统的耗时大头在网络往返、数据库查询和业务逻辑上，加解密只是请求链路里的一小段，而SM4处理批量数据的速度足够快，分摊到每个请求上的开销就被摊薄了。真正需要提前算账的是三类用法：高频签名验签、海量数据全量加密、短连接高频握手。

1. 传输加密：链路里占比最小的一环

业务系统接入国密TLS传输协议后，握手阶段用SM2完成证书验证和密钥协商，连接建立后的业务报文由SM4加密、SM3校验。SM2的开销集中在握手那一次，之后每笔请求走的都是SM4的对称加解密。公开的通用测试环境里，开启硬件加速的SM4吞吐能达到每秒数GB量级，普通业务系统的报文流量离这个上限很远，传输加密在请求总耗时里的占比自然很小。

2. 存储加密：范围和数据量决定开销

数据库字段加密、附件加密属于存储侧改造，开销取决于两个变量：加密多少数据、用什么实现。只对身份证号、银行卡号、手机号这类敏感字段做加密，单条记录增加的耗时以微秒计，用户完全察觉不到；如果整库整表全量加密，每次读写都要过一遍加解密，开销就转嫁到每一笔交易上，这时硬件加速和加密范围的设计就成了关键。

3. 签名验签：频率是放大器

SM2是非对称算法，单次签名和验签的耗时天然比SM4这类对称算法高两到三个数量级，这是算法类型决定的，国际算法里ECDSA相对AES同样是这个关系，不是国密特有的短板。单次调用感觉不到差别，但如果每笔业务请求都要一次签名加一次验签，并发一高，SM2的耗时就被频率成倍放大，这是国密改造里最需要提前做性能评估的场景。

损耗的大小，三分在算法，七分在用法。

二、SM2和SM4的分工：慢的签名，快的扛量

很多性能争议源于把两个算法混为一谈。SM2和SM4不是二选一的关系，而是分工关系，实际系统里它们总是搭档出现，各管一段。

1. SM2：管签名、验签和密钥交换

SM2是基于椭圆曲线的公钥密码算法，对标国际的ECDSA，解决的是身份认证和密钥分发两件事：数字签名证明这份数据确实出自持钥方、且没有被篡改，密钥交换让通信双方在不安全的信道上协商出共享密钥。公钥算法的单次运算慢是天性，所以它只处理摘要和密钥这类几十字节的小数据，不直接加密业务数据。

2. SM4：管数据本身的加解密

SM4是分组对称密码算法，密钥长度和分组长度都是128位，对标AES-128。对称算法加解密共用一个密钥，运算结构简单，单次处理快，天然适合批量数据。纯软件实现的SM4和软件实现的AES处于同一量级；在支持国密指令集的CPU上，SM4还有硬件加速路线，吞吐能再上一个台阶。

3. 数字信封：两个算法的标准组合

工程里的常规做法叫数字信封：发送方随机生成一个SM4会话密钥，用它加密业务数据，再用接收方的SM2公钥加密这个会话密钥，两者一起发出。接收方先用SM2私钥解出会话密钥，再用SM4解开数据。慢的算法只碰几十字节的密钥，快的算法扛全部业务数据，这个组合本身就是性能方案。

让慢算法只签名、快算法扛数据，加密性能问题就解决了一半。

三、benchmark怎么测才可信

网上流传的测试数据经常打架：同样对比国密和国际算法，有人测出两三成的损耗，有人测出来几乎无感。差别多半不在算法，在测法。想拿到能支撑决策的数据，四件事要先钉死。

1. 基线必须同环境同负载

对比组和实验组要跑在同一台机器、同一时段、同一负载模型上，只切换算法这一项变量。拿A环境测的国密数据和B环境测的国际算法数据做对比，结论没有意义。

2. 先确认运行环境支持什么

同一份SM4代码，跑在不支持国密指令集的老服务器和新的国产化硬件上，结果完全不同。测试报告里必须写清CPU型号、操作系统、JDK或OpenSSL版本、底层用的哪个密码Provider，这些条件缺一项，数据就无法复现。

3. 别只看平均值

平均值会被长尾请求掩盖。接口类测试要看P95、P99分位耗时，连同吞吐量、错误率一起看。国密改造影响的常常不是平均响应时间，而是高并发下的长尾表现，只盯平均值会把问题漏掉。

4. 负载模型要贴近真实业务

拿1KB的表单报文和拿10MB的附件做测试，得出的损耗比例天差地别。正确做法是从生产环境取样报文大小分布和并发曲线做回放，这样测出的数字才能外推到上线之后。

环境说不清楚的测试数据，不要拿去做上线的决策。

四、四个典型场景的损耗画像

把前面的方法落成场景。企业管理系统里最常见的四类国密用法，损耗特征各不相同，可以对照自己的系统对号入座。

1. 管理系统走国密TLS

内部管理系统并发有限、连接以长连接为主，握手开销摊到整个会话周期后接近于零，业务报文的SM4开销在请求总耗时里占比很小。这类改造用户侧的实际感受就是两个字：无感。

2. 数据库敏感字段加密

按字段加密的设计下，只有身份证、卡号、手机号这类列走加解密，其余列保持明文，单行读写增加的耗时在毫秒以内。设计时把加密列排除在模糊查询和范围查询之外，整体查询性能的波动就能控制在很小的范围。

3. 附件与文件批量加密

这是吞吐型任务，损耗直接由实现方式决定，纯软件实现和硬件加速之间差距明显。这类场景的优化重点不在算法选型，而在部署环境：支持国密指令集的CPU、密码卡、独立部署的加解密服务，哪个性价比高，测了才知道。

4. 高频电子签章与验签

审批流每个节点都调签、服务端逐笔验签的场景，SM2的单次耗时乘以调用频率就是总账。常规解法是把验签服务独立部署、通过消息队列做批量异步处理，把签名的负载从业务主链路上摘出去，业务响应时间就能回到改造前的水平。

场景不同，损耗能差出一个数量级，别人的结论套不到你的系统上。

五、把损耗压下去的五个做法

性能问题九成出在工程实现而不是算法本身。五个做法按见效程度排序，多数系统做完前三项就够了。

1. 收窄加密范围

只加密法规和监管明确要求的敏感字段，不做全量加密。加密的数据量每降一个量级，损耗同步降一个量级，这是所有优化里成本最低、见效最直接的一步，应该在方案设计阶段就定下来。

2. 会话复用与长连接

国密TLS支持会话复用和连接保活，避免每个请求都重新走完整握手。SM2的开销集中在握手阶段，会话复用等于直接砍掉了重复的握手计算，对高并发短请求的接口场景收益明显。

3. 用上硬件加速的运行环境

选型时确认服务器CPU、密码卡和软件Provider对SM2/SM4加速的支持情况。批量加解密场景下，这一项带来的吞吐改善常常超过其余优化之和，值得在采购阶段就写进技术要求。

4. 验签异步化

高频验签从同步链路改成消息队列驱动的异步任务，业务接口的响应时间立刻回落，验签吞吐靠横向扩容解决。签名保留在发起、审批、归档这类关键节点，中间流转节点用摘要传递，调用频率就降下来了。

5. 加密收敛到平台层

每个应用自己写加密代码，实现质量参差不齐，性能和安全都没法统一保障。把国密能力收敛到平台层统一实现、统一调优，应用只做配置选择，是规模化改造的常规路线，搭贝走的也是这条路。

先收窄范围，再谈硬件投入，顺序反了就是白花钱。

六、搭贝在国密改造里的位置

国密改造的完整链条包括算法、证书、密钥管理、应用适配多个层面，搭贝的位置在应用层：平台内置国密算法支持，传输层对接国密TLS，存储层提供字段级和附件级加密选项，签名验签封装成可配置的服务，密钥管理对接统一的密码基础设施。

用搭贝搭建的业务应用，国密改造在平台层一次完成：加密实现由平台统一维护和调优，上面的每个应用不需要重复开发加密代码，也不需要自己踩性能的坑。对做改造的企业来说，这意味着安全合规的工作量集中在一处，应用开发和业务调整照常推进。授权按用户数报价，国密能力包含在平台能力里。

应用无感，是平台型国密改造最直接的性能红利。

常见问题