国密算法性能实测：SM2到SM4全流程

（平台提示：本文可能是商业推广软文）

国密改造前最实际的问题是性能会掉多少。SM2签名验签、SM3摘要、SM4加解密的实测数据，叠加到真实业务链路上的耗时变化，这篇用一组测试环境数据回答。

国密算法替换后系统到底慢多少，这是国资监管平台做密评改造时最实际的问题。本文围绕SM2、SM3、SM4三类国密算法的性能展开，用搭贝在测试环境里跑出的实测数据，把大家最关心的加解密速度、签名耗时、握手开销一次讲清楚，最后给出改造优先级的建议。

一、为什么性能是国密改造绕不开的坎

密评和等保要求落地之后，国资系统里的国际算法要逐步换成国密算法。替换本身不难，难的是替换之后的影响评估：接口响应会不会变慢，批量任务会不会超时，证书握手会不会堆积连接。这些问题不提前测清楚，上线之后就是被动救火。

1. 三类算法各管一摊

SM4是对称算法，负责数据加解密，对应国际的AES；SM3是哈希算法，负责摘要和完整性校验，对应SHA-256；SM2是非对称算法，负责签名验签和密钥交换，对应RSA和ECC。性能焦虑主要集中在这三类算法的耗时差异上。

2. 国资系统的三个高消耗场景

一是文件加密，监管上报的报表、审计材料动辄几十MB，SM4的吞吐直接决定任务时长。二是接口签名，集团内部系统互相调接口，每次请求都要过一遍SM2签名和验签。三是HTTPS握手，换成国密SSL证书后，建连耗时影响所有在线操作。

3. 差距要分算法看，不能一刀切

很多单位一听国密算法就默认性能损失很大，这是把三类算法混为一谈了。对称和哈希这两类，替换前后几乎无感；真正拉开差距的是非对称算法那一环。后面几节会分别给出三类算法的实测数据，每组数据都附上和国际算法的对照，方便直接评估自己系统的替换成本。本节小结：先知道自己的系统卡在哪类场景，再去对照后面的数据。

二、实测环境与测试方法

数据不是凭感觉说的。搭贝在测试环境里对三类算法做了单独压测，方法如下。

1. 环境配置

测试机为普通x86服务器，8核CPU、16GB内存，未使用加密卡等硬件加速，算法实现采用开源国密库的纯软件版本。这个配置比很多生产环境要低，所以下面的数据偏保守，实际生产多数会更好。选择纯软件实现，是为了让没有加密卡预算的单位也能直接参考。

2. 测量口径

对称和哈希算法测吞吐，单位MB/s，样本为随机生成的1GB数据文件；签名验签测单次耗时，单位毫秒，每项循环一万次取平均值；握手测试用国密SSL证书建立连接，统计建连总耗时。每项测试跑三轮，取中位数，避免单次抖动。本节小结：数据是软件实现的参考量级，上了硬件加速后差距会进一步缩小。

三、SM4对称加解密：批量文件的主力

SM4承担了系统里大部分的数据加密工作，它的吞吐决定了文件加密和存储加密的实际体验。

1. 实测吞吐

在测试机上，SM4软件实现的加解密吞吐稳定在400MB/s到500MB/s之间，加密与解密速度基本一致，CBC和ECB模式差异不大。作为对照，同环境下的AES-128约为600MB/s到700MB/s。也就是说，纯软件场景下SM4比AES慢三成左右，但绝对速度已经够用：一个100MB的监管报表，加密耗时约0.2秒，批量任务里几乎感觉不到。

2. 对业务的真实影响

按这个吞吐倒推，每天加密10GB数据，SM4比AES多花约10秒，分摊到定时任务里完全可以忽略。真正要留意的是单线程小文件场景，几十KB的小文件频繁加解密时，函数调用和文件IO的开销占比上升，算法本身反而不是瓶颈，建议做批量合并处理。

3. 一个容易被忽略的细节

SM4的密钥长度固定为128位，不存在像AES那样在128、192、256之间选择的纠结，安全强度对国资监管类系统完全够用。部分老系统的存储字段是按十六进制密文长度设计的，SM4密文长度与AES一致，替换后不用改表结构，这一点在做存量数据迁移时能省不少事。本节小结：SM4替换AES对绝大多数业务无感知，放心换。

四、SM3哈希摘要：几乎不用担心的那一环

SM3在三类算法里存在感最低，因为它实在太快了，快到多数场景可以忽略不计。

1. 实测吞吐

SM3软件实现的摘要吞吐在800MB/s到1GB/s之间，与SHA-256处于同一量级，差距在10%以内。计算一个1GB文件的摘要耗时约1秒出点头，日常的接口报文校验、配置文件完整性检查，单次耗时都在微秒级，业务上不会有任何感知。

2. 唯一要注意的大文件场景

只有两类情况需要留意SM3的耗时：一是对GB级的备份文件做全量摘要，二是每次请求都重复计算大报文摘要。前者建议改成增量或分段摘要，后者建议加一层结果缓存。除此之外，SM3可以无脑替换，不需要做任何性能优化。本节小结：SM3替换零负担，改造时优先级可以放最低。

五、SM2签名与握手：性能差距的真正来源

前面两类算法都不用太担心，国密改造的性能开销主要压在SM2上，这也是实测数据里差距最明显的一环。

1. 签名验签耗时

实测SM2单次签名耗时在0.5毫秒到1毫秒之间，验签在1毫秒到2毫秒之间。对照同环境的RSA-2048，签名约8毫秒、验签约0.3毫秒。也就是说，SM2签名比RSA快很多，但验签比RSA慢数倍。业务影响要看方向：系统大量做签名、少量做验签，换SM2反而变快；反过来，网关或验签服务每秒要验几万次签名，就必须认真评估。

2. 国密SSL握手开销

用国密SSL证书建连，单次握手总耗时比普通TLS1.2握手多出约两毫秒到五毫秒，来自SM2签名验签和密钥交换的额外计算。对用户一次页面访问来说无感，但高并发建连场景下这个开销会叠加，长连接和会话复用能把它摊薄。这里的建议是：内网服务间调用启用连接池，对外Web服务开启会话票据复用，握手开销就不再是问题。本节小结：SM2的差距集中在验签和握手两端，都有成熟的应对手段。

六、三个可以直接用的改造结论

数据看完了，落到国资系统的密评改造上，结论其实很简单。

1. 替换顺序建议

先换SM3和SM4，这两项零风险无感知；再换证书和握手层面的SM2，配合连接池上线；最后处理高频验签链路，必要时给验签服务单独扩容，或者在高并发节点上引入加密卡。按这个顺序走，整个改造过程业务方基本无感。

2. 什么时候需要硬件加速

软件实现扛不住的判断标准很简单：验签QPS超过单核处理能力，或者握手并发导致连接堆积。到这一步再考虑加密卡，成本可控。绝大多数地市级的国资监管系统，纯软件实现加上连接复用就足够了，不必为用不上的算力买单。搭贝的密评改造方案按用户数报价，不同规模的平台可以按需选择。本节小结：先软件后硬件，按实测数据决策，不预支成本。

常见问题

Q：搭贝在这类改造里提供什么？

提供从现状摸排、算法替换、性能压测到密评支撑的完整服务，本文的数据就来自改造过程中的标准压测环节。方案按用户数报价，国资监管平台可以先做小范围试点，再全面铺开。
Q：没有加密卡，纯软件国密能过密评吗？

能。密评考察的是算法正确应用，不是硬件配置。搭贝接触的改造项目里，大量系统用纯软件实现通过了密评，性能达标的关键在连接复用和链路优化，不在硬件。

Q：改造要不要停机？业务会不会中断？

分算法看。SM3和SM4可以随版本迭代逐步替换，不停机。证书和握手层面的SM2替换需要短暂的切换窗口，通常安排在夜间低峰，分钟级完成。整体上属于平滑改造，不需要长时间停业务。

Q：国密算法整体比国际算法慢很多吗？

实测来看不是。SM3与SHA-256同量级，SM4比AES慢三成但绝对速度够用，只有SM2的验签比RSA慢数倍。三类算法叠加到真实业务里，多数场景的总耗时变化在毫秒级，用户无感知。担心性能不如先测高频链路的实际耗时，用数据说话。

搭贝官网：https://www.dabeicloud.com