📚 课程目录第1章国密算法概述

一、国密算法概述

做微服务集成这么多年，我经常被问到：「你们用国密了吗？」说实话，这个问题背后其实是个大工程。国密算法不是一套简单的加密工具，而是我们国家在密码学领域自己制定的标准体系。今天咱们就从头捋一捋，把国密算法的基础打扎实。

国密，全称「国家商用密码算法」。它由国家密码管理局发布，是一整套密码学标准。为什么要有这套东西？说白了，商业密码不能全依赖国外算法，万一卡脖子怎么办？

我经历过一个政务项目，客户要求所有数据通信必须用国密。一开始我还有点懵，后来发现国密体系和常见的国际算法（比如RSA、AES）其实是对应得上的。看下面这个表格就清楚了：

嗯，SM9也是国密，但在微服务集成里用得相对少一些。咱们这章重点讲SM2/SM3/SM4，因为这是微服务国密集成的「三大件」。

SM2基于椭圆曲线密码学（ECC）。你可能会问：「ECC和RSA比，到底强在哪？」说白了，同样安全强度下，SM2的密钥更短，计算更快。

举个例子：一个128比特的安全强度，RSA需要3072位密钥，而SM2只需要256位。我在做证书签发服务的时候，SM2的签名性能比RSA快了将近3倍——这个差距在并发场景下非常明显。

SM2的核心用途：

📌 微服务里最常用的是SM2签名验签，比如JWT的签名，或者服务间调用的请求签名。我建议尽量用SM2withSM3的签名模式，安全和性能兼顾。

SM3是国密标准的哈希算法，输出256位摘要。和SHA-256比，SM3的结构设计稍微更复杂一些，安全性也更高——至少从密码学分析角度来看，SM3的抗碰撞性优于SHA-256的一个变种（比如SHA-256的缩减轮）。

注意一个细节：SM3的输出长度为32字节，这个和SHA-256一样。所以在微服务里，凡是需要哈希的地方（比如完整性校验、数字签名的预处理）都可以直接用SM3替换SHA-256，数据结构基本不变。

⚠️ 我曾经遇到一个坑：有些国密SDK的SM3实现，对大文件做哈希时内存管理有bug。建议分段读取文件，调用SM3的update方法，别一次性读全部。

SM4是一种分组对称加密算法，分组长度128位，密钥长度也是128位。它和AES-128本质上是对等的，但轮函数和密钥扩展算法不同。SM4里有个小特征——它用非线性S盒和线性变换组合，抗差分分析能力不错。

SM4支持多种工作模式：

我个人习惯是：传输加密用CTR或GCM，存储加密用CBC。为什么？CTR模式可以并行计算，性能更好；GCM自带认证标签，防篡改。CBC模式则适合固定长度的数据块加密。

差异点其实就三个维度：算法本身、实现方式、合规要求。我把核心区别整理成一张表：

对比维度	国密算法	通用算法
算法公开性	国家标准公开，但早期有专利限制	RFC/ISO标准，完全开放
性能	SM2/SM3/SM4在软实现中略慢于国际对标（约10%~20%）	RSA/AES有硬件优化，速度更快
合规要求	国内政务、金融、关键基础设施必须使用	海外通用，国内部分场景不认可
算法安全性	SM2/SM3/SM4均经过国家密码局审查	长期验证，但部分算法（如RC4）已不推荐
生态支持	OpenSSL 1.1.1+已支持，但Java/BouncyCastle需额外配置	所有主流语言和框架原生支持

💡 结论：国密和通用算法没有「谁更强」的关系，只是标准不同。微服务集成的核心挑战不是算法本身，而是如何无缝替换——比如把AES加密换成SM4，同时不破坏模块的整体架构。

下面这张图梳理了国密算法在微服务集成中涉及的关键概念与技术路径，方便你快速定位。我建议你把它当作一个「思维导图」来用。

你可能觉得「直接用OpenSSL加个参数就能搞定」，但实际情况没那么简单。我遇到过几个典型问题：

算法库兼容性：JDK 8原生不支持国密，需要引入Bouncy Castle或者使用华为/BabaSSL等第三方库。我在Spring Boot项目里就用过BC提供者，配置不当会导致密钥格式报错。
密钥格式不统一：SM2的公钥可以以X509格式存储，但有些国密网关要求用PEM with ASN.1，有些则用原始16进制。这一步很容易对接失败。
性能衰减：如果微服务每秒处理上千个签名请求，SM2的软实现可能成为瓶颈。我建议用硬件密码模块（如PCI-E密码卡）或者国密专用芯片来加速。

⚠️ 警告：不要盲目「把AES改成SM4就完事」。微服务里加密方式改变了，密钥管理策略、接口设计、日志脱敏策略都得跟着改。我曾经因为只改了加密算法，没改密钥轮换策略，结果被安全审计打回了。

话说回来，这些困难不是劝退你的理由。理解了基础差异，后面咱们一章一章拆解具体集成步骤，你会发现其实没那么复杂。这章的知识结构，就是后续所有实践的「根」。