1. 课程概览：国密算法背景、SM2与SM3应用场景、SDK性能优化总览与核心瓶颈分析

1.1 为什么我们需要国密算法

先说说背景吧。我刚接触国密那会儿，是2017年帮一家金融机构做等保三级改造。客户要求核心交易系统必须用国产密码算法替代RSA和SHA-256。说实话，一开始我对这个要求有些不解——RSA那么成熟，为什么要大动干戈？

后来深入理解才发现，国密算法不只是“换一个加密函数”那么简单。你想想看，密码算法的安全性与国家信息安全战略紧密相关。国密SM2/SM3/SM4系列算法由国家密码管理局发布，在金融、政务、电力、通信等关键基础设施领域，现在已经强制要求使用。

我个人习惯把这件事总结为三个驱动因素：

• 合规驱动：等保2.0、密评（密码应用安全性评估）都明确要求使用国密算法，不做就过不了审。
• 安全驱动：SM2基于椭圆曲线密码（ECC），比RSA同等安全强度下密钥更短、性能更优；SM3杂凑算法输出256位摘要，安全性对标SHA-256。
• 自主可控：关键基础设施不能依赖国外算法，这个道理你懂的。

1.2 SM2与SM3的应用场景

SM2和SM3在真实系统中是怎么落地的？我参与过的几个项目大概能说明问题。

算法	典型场景	我用过的实际案例
SM2	数字签名、密钥协商、公钥加密	银行柜面系统的交易签名、电子政务的公文盖章
SM3	消息摘要、完整性校验、HMAC	日志完整性保护、软件包哈希校验、区块链区块链接

为什么会分开说？因为两者的优化侧重点完全不同。

1.3 SDK性能优化总览

所谓“性能优化”，说白了就是让SM2签名验签、SM3哈希运算跑得更快，同时少占CPU、少等内存。我总结了三大优化主题：

1. 算法本身的优化：比如SM2的基点乘（scalar multiplication）如何用NAF窗、Montgomery阶梯等方式加速；SM3的消息扩展和压缩函数如何做指令级并行。
2. 内存与访存模式优化：SDK在运行时大量分配临时缓冲区，密码运算又是数据密集型操作，缓存不命中、内存碎片都是隐形杀手。嗯，这里要注意——你以为瓶颈在算法层，其实很多时候都在内存分配上。
3. 适配层开销优化：SDK往往需要同时暴露多种接口（如OpenSSL风格、Java JCE、Golang crypto接口）。每多一层封装、每多一次数据拷贝，性能就掉一截。

1.4 核心瓶颈分析

在实际优化中，我遇到过最多的瓶颈可以归纳为以下几类。我列个清单，你对照着看看自己项目中招了没：

• SM2点运算太慢：尤其是秒级验签场景。我曾经遇到一个物联网网关，每秒需要验签2000次，结果SDK默认实现只能做到300次/秒——差距太大。
• SM3短消息哈希效率低：SM3的压缩函数每轮处理512位（64字节），如果消息很短（比如几十字节），会频繁做填充和消息扩展，吞吐上不去。
• 大对象分配导致GC压力：Java和Go这种带GC的语言尤其明显。每次签名new一个对象，在高并发下GC会吃掉一半CPU。
• 上下文切换和锁竞争：多线程调用同一SM2私钥签名时，SDK内部用全局锁保护密钥——这几乎是性能杀手第一名。
• 端序与对齐问题：SM2/SM3的数据表示是大端序，但x86处理器是小端序。我曾经踩过一个坑：一个for循环里逐字节倒序，结果跑了30毫秒才完成一次SM3更新——改用一次性8字节反转指令后，直接降到2微秒。

1.5 本章知识体系框架

下图是我梳理的本章核心脉络。你把它当作一个导航图，后面每章节都会围绕这里提到的要素展开。

这个图把本章的五个核心模块串起来了。从上到下看：先理解国密算法背景和合规驱动力，然后区分SM2和SM3各自的服务场景，接着进入优化总览——分为算法层、内存与访存层、适配层三个维度，最后落到真实项目中常见的五类性能瓶颈。后面29个章节，每一个都会深入这个图中的某一个区块，逐个击破。