第1章 国密算法概述：SM2/SM3/SM4/SM9 算法家族及应用场景
说实话，搞国密这些年，最常被问的问题就是：「SM2、SM3、SM4、SM9 到底啥关系？用的时候怎么搭？」 很多人一上来就把这些算法当「零件」看，觉得能用就行。但我个人习惯是——先搭架子，再填零件。所以这一章，我们先把这个「架子」看清楚。
1.1 国密算法核心成员
国密算法家族目前公开的主力算法其实就四位：SM2、SM3、SM4、SM9。每个算法各自有擅长的领域，有点像厨房里的刀、案板、锅、灶——各有各的活儿。
| 算法 | 类型 | 核心能力 | 对标国际 |
|---|---|---|---|
| SM2 | 公钥密码（椭圆曲线） | 数字签名、密钥交换、加密 | ECDSA / ECDH |
| SM3 | 密码哈希 | 数据完整性、消息摘要 | SHA-256 |
| SM4 | 对称分组密码 | 数据加密、解密 | AES |
| SM9 | 标识密码（基于双线性对） | 数字签名、密钥封装、加密 | IBC（Identity-Based Cryptography） |
个人经验： 我曾在项目中看到有人用 SM4 给证书私钥加密，但密钥管理本身却用了明文存——这就像锁了保险柜，钥匙却挂在门外。算法选对只是第一步，密钥边界设计才是真正的大坑。
1.2 算法家族总览图
先别急细节，我们看一张整体关系图，把四个算法及其典型应用场景串起来。这是我经常在方案里画的一张图，能帮团队快速对齐上下文。
说白了，这张图就是告诉你：SM2 和 SM9 解决「谁是谁」的问题（身份与签名），SM3 解决「改没改」的问题（完整性），SM4 解决「怎么藏」的问题（机密性）。 后面的课程会反复回到这张图来对齐边界。
1.3 应用场景归纳
每个算法都不是孤立存在的，实际工程中经常组合出现。我根据自己踩过的坑，列几个典型场景：
- 电子签章 / 合同： SM2 签名 + SM3 摘要。注意！签名前一定要用 SM3 算哈希，否则大数据签名性能会崩。我曾经见过有人直接把整个合同原文用 SM2 签名——结果跑了一分钟还没出来。
- SSL/TLS 国密套件： 握手阶段用 SM2 交换密钥，然后用 SM4 加密封装会话。SM3 则用于握手消息的完整性校验。
- 标识密码场景（无证书环境）： SM9 可以直接用用户手机号或域名做公钥，适合 IoT、邮件加密等不需要 PKI 的场景。但注意——SM9 的密钥托管是个双刃剑，小心设计分发策略。
- 区块链： 哈希用 SM3，账户签名用 SM2，交易数据加密用 SM4。简单直接。
核心观点： 密钥边界兼容性设计的本质，就是搞清楚「哪个算法该管哪一段密钥」。例如 SM2 私钥只能在签名客户端使用，SM3 不需要密钥，SM4 的密钥必须由 SM2 或 SM9 协商分发——这个逻辑链条不能乱。
1.4 避坑指南
嗯，这里我要多说几句。我曾经在某个政务项目中，发现团队把 SM4 密钥直接用 SM3 哈希后当作会话密钥——这其实是不安全的，因为 SM3 是单向摘要，不是密钥派生函数（KDF）。
警告： SM3 不能替代密钥派生算法（如 KDF2）。如果你需要从共享密钥中派生多个会话密钥，请使用标准密钥派生函数，不要直接用 SM3 裸算。否则密钥之间可能产生关联性，被侧信道攻击利用。
还有一点：SM9 的私钥由密钥生成中心（KGC）生成，这在某些合规场景下可能涉及「密钥托管」问题。如果客户要求私钥完全由自己控制，那 SM2 才是正确选择。
1.5 一句话总结本章
国密算法家族四个成员：SM2 公钥、SM3 哈希、SM4 对称、SM9 标识。每个都有自己最擅长的位置，组合使用时，先画关系图，再定谁的密钥归谁管。你想想看，密钥边界不清，后期改起来有多痛苦？还是早规划早安心。