国密算法概述：从为什么用到怎么用

做金融行业国密改造，第一个绕不开的词就是“国密算法”。很多Java工程师第一次接触国密时，第一反应是——“这玩意儿跟AES、RSA有啥区别？”我当年也一样，看标准文档看到头大。今天咱们把这个话题拆开揉碎了讲清楚。

国密算法为什么会出现？

说白了，就两个原因：

• 安全自主可控——RSA、AES、SHA这些算法都是国外标准。万一哪天突然不让用了？金融系统停摆可不是闹着玩的。我在某银行做咨询时，亲耳听安全总监说过：“国际算法是好，但命门不在自己手里。”
• 合规必须过——人民银行、银保监会、国家密码局都有明确要求。金融核心系统、网上银行、手机银行，必须使用国密。这不是“选配项”，是“必选项”。

所以，国密不是技术问题，是合规问题。技术选型的时候，你先把这个认知锚定住。

国家密码局标准和SM系列家族

国家密码局发布的SM系列算法，目前最常用的就是四个：

算法名称	算法类型	对标国际算法	密钥/分组长度	主要用途
SM1	对称加密（硬件实现）	—（无直接对标）	128位	加密敏感数据
SM2	非对称加密/签名	RSA / ECDSA	256位公钥	密钥交换、数字签名、证书
SM3	哈希算法	SHA-256	输出256位摘要	完整性校验、消息认证
SM4	对称加密（软件实现）	AES-128	128位分组/128位密钥	金融数据加密、通信加密

SM2、SM3、SM4 深入对比

这几个算法，我一个个说。

SM2：国密的“门面担当”

SM2是非对称算法，基于椭圆曲线密码学（ECC）。它和RSA最大的不同是：同样安全强度下，SM2的密钥短、速度快。RSA要用2048位才能做到128位安全等级，SM2用256位就够了。我在做支付网关签名改造时，SM2签名的耗时只有RSA2048的1/3左右。这个性能差距，在高并发场景下非常明显。

SM3：不能小看的哈希

SM3输出256位哈希值，结构和SHA-256类似，但做了一些改进。它的抗碰撞能力经过多轮分析，安全性是可靠的。金融行业用SM3做交易完整性校验、数字信封、证书指纹。嗯，我记得有一次帮客户做网银改造，接口签名验签一直报错，排查半天发现是SM3摘要长度不对——32字节，不是64字节。这个细节容易踩坑。

SM4：对称加密的“芯”

SM4是对称分组密码，分组长度128位，密钥也是128位。结构类似AES，但有自己独特的S盒和线性变换。它在金融数据加密、TLS国密套件、磁盘加密等场景用得最多。性能相当不错，纯软件实现也能达到几百MB/s的吞吐量。

国密 vs 国际算法：差异清单

为了让你一目了然，我列个对照表：

对比维度	国密（SM系列）	国际算法（RSA/AES/SHA）
标准化主体	中国国家密码管理局	NIST / IETF / ISO
算法公开性	SM2/SM3/SM4完全公开（SM1仅提供硬件）	完全公开
安全强度	128位安全级别（主流）	128~256位（可选择）
标准文档	GB/T 32918（SM2）、GB/T 32905（SM3）、GB/T 32907（SM4）	FIPS PUB 186（RSA）、FIPS PUB 197（AES）、FIPS PUB 180（SHA）
金融合规	境内金融系统强制要求	仅用于跨境/对客场景
实现难度	中等（开源库成熟）	低（OpenSSL、Bouncy Castle原生支持）
生态成熟度	国内通用，跨境支持少	全球通用，生态极丰富

为什么国密生态“国内通用、跨境支持少”？我举个例子。你在美国AWS的KMS里，是找不到SM4的。你用OpenSSL 1.1.x，默认也不编译国密。你在跨境支付或者国际银联合作时，对方可能根本不认识SM2的证书格式。这些是实实在在的坑。所以在做架构设计时，国际算法做兼容，国密做主通道，这是比较稳妥的策略。

核心逻辑一张图说清楚

下面这张SVG图把国密体系的核心框架画了出来。你可以把它当作整章的知识索引。

归纳总结：国密如何选、怎么用

讲到这里，我做一个简单总结。做国密改造，记住几个选择原则：

• 加密数据传输？用SM4做对称加密。速度快，适合大块数据。
• 数字签名/验签？用SM2。银行转账签名、支付接口签名，基本都用它。
• 完整性校验？用SM3。比对摘要、证书指纹，都是它。
• 密钥协商？还是SM2。这类椭圆曲线密码天然适合做密钥交换。

曾经有一个金融项目，客户坚持所有数据都用SM2加密——这其实是个误解。非对称加密速度慢，适合加密短数据（比如对称密钥、哈希值），不适合加密几十KB的交易报文。嗯，理解每个算法的定位，比死记硬背API更重要。

下一步，也就是后面的章节，我们会深入到每个算法的具体Java/C++ SDK调用方式。但现在，你已经有了全局视野——这比什么都重要。