4. 密码算法与协议选型实践
算法选型不是“国密一定优于国际算法”或“国际算法更成熟”的简单判断，而是把业务合规要求、对端互操作能力、性能约束、密钥与证书体系现状四个条件同时代入，再落到具体协议参数上的工程决策。本章围绕 SM2/SM3/SM4/SM9 与 RSA/ECC/AES/SHA 的适用边界，结合 TLS、IPSec、SSH、S/MIME 四类典型协议，给出一套可直接使用的选型矩阵与落地方法。
一、先分清算法层次，再谈替换
选型混乱的根源，往往是把不同层次的算法混在一起讨论。密码算法在协议中承担四类彼此独立的职责：
- 非对称加密/密钥交换：RSA、ECC(ECDH/ECDSA)、SM2、SM9。负责身份认证与密钥协商。
- 对称加密：AES、SM4。负责数据体加密，决定吞吐性能。
- 哈希/摘要：SHA-256/SHA-384、SM3。负责完整性校验与签名预处理。
- 标识密码：SM9。以用户标识（如邮箱、工号）为公钥，省去证书链，适合大规模终端与物联网场景。
关键结论是：对称算法与哈希算法的替换成本低、性能影响小，通常可以优先国密化；非对称算法的替换会牵动证书体系、CA、对端信任链，成本最高。因此实际项目中常见的策略是“SM4+SM3 先行，SM2 随证书体系改造推进，SM9 用于特定无证书场景”。
二、算法适用场景对照
| 算法 | 类型 | 典型密钥/摘要长度 | 适用场景 | 主要限制 |
|---|---|---|---|---|
| RSA-2048/3072 | 非对称 | 2048/3072 位 | 存量 TLS 证书、S/MIME 签名与加密、老系统兼容 | 密钥长、握手慢、无前向保密（静态 RSA 套件） |
| ECC P-256 | 非对称 | 256 位 | 移动端 TLS、ECDHE 前向保密、资源受限设备 | 部分国产环境合规性不足 |
| SM2 | 非对称 | 256 位 | 国密 TLS 双证书、签名验签、密钥交换 | 需国密 CA 与支持 SM2 的协议栈 |
| SM9 | 标识密码 | 256 位 | 无证书终端认证、邮件加密、IoT 身份 | 依赖 KGC 密钥生成中心，标准支持面窄 |
| AES-128/256-GCM | 对称 | 128/256 位 | 通用数据加密、TLS 记录层、IPSec ESP | 无合规障碍，性能优 |
| SM4-GCM/CBC | 对称 | 128 位 | 国密 TLS/IPSec、本地数据加密、VPN | 需硬件或软件实现支持 |
| SHA-256/384 | 哈希 | 256/384 位 | 签名摘要、HMAC、证书指纹 | — |
| SM3 | 哈希 | 256 位 | 国密签名摘要、HMAC-SM3、完整性校验 | 需协议栈支持 |
三、协议层的选型落点
算法最终要绑定到协议的密码套件或安全提议上，四类协议的落点差异明显：
- TLS/SSL：国密场景使用双证书体系，套件形如
TLS_SM4_GCM_SM3，签名算法 SM2-with-SM3，密钥交换 SM2 或 ECDHE-SM2；国际场景推荐TLS_AES_256_GCM_SHA384+ ECDHE-P256，禁用 RSA 静态密钥交换与 CBC 套件。 - IPSec：IKE 阶段用 SM2/ECDSA 做身份认证，ESP 阶段用 SM4-GCM 或 AES-GCM 加密，完整性用 SM3-HMAC 或 SHA-256-HMAC。注意 IKEv2 的 SA 提议需两端算法集有交集。
- SSH：主机密钥算法可选 SM2 或 Ed25519/ECDSA，密钥交换用 SM2 或 curve25519-sha256，对称加密用 SM4-CTR 或 aes256-gcm，MAC 用 hmac-sm3 或 hmac-sha2-256。
- S/MIME：邮件签名与加密依赖证书，国密改造需 SM2 证书 + SM3 摘要 + SM4 内容加密，且收发双方邮件客户端都要支持。
判断某协议能否国密化，先看三个问题：协议栈是否支持该算法套件？对端是否支持？证书/密钥体系是否已就绪？三者缺一，强行替换只会导致连接失败。
四、选型矩阵与决策路径
把上述判断固化为矩阵，可以在项目评审时快速定位。下图给出从业务条件到协议套件的决策路径，以及四类协议的算法落点关系。
五、落地示例：一条国密 TLS 连接的参数核对
以某企业内网 Web 系统国密改造为例，服务端使用支持国密双证书的网关，客户端为国产浏览器。改造后需要核对的关键参数如下（示例配置，非实测结果）：
# 服务端国密 TLS 关键参数（示例）
sign_cert: SM2 签名证书（由国密 CA 签发）
enc_cert: SM2 加密证书（双证书体系）
cipher_suite: TLS_SM4_GCM_SM3
key_exchange: SM2（或 ECDHE-SM2）
sign_algo: SM2-with-SM3
tls_version: TLS 1.2 / GM-TLS 1.1
# 客户端核对项
1. 是否信任国密根 CA
2. 是否支持 SM2 双证书校验
3. 是否启用 SM4-GCM 套件
4. 握手日志中协商结果是否为 SM 系列判断改造是否成功的依据不是“配置写对了”，而是握手日志中实际协商出的套件、证书类型和签名算法三项都落在国密集合内。若协商结果回落到 AES 或 RSA，说明某一端不支持或优先级配置有误，需要逐项排查。
六、选型矩阵的使用建议
把矩阵落到项目上时，建议按以下顺序推进：
- 先定合规底线：明确哪些链路、哪些数据必须国密，避免全量改造。
- 再查对端能力：对每个协议列出两端支持的算法集，取交集作为可用集。
- 对称与哈希先行：SM4、SM3 替换风险低，可优先落地并验证性能。
- 非对称随证书体系推进：SM2 需要 CA、证书模板、吊销机制同步改造。
- SM9 用于特定场景：无证书、大规模标识认证场景再引入，避免为用而用。
- 保留国际算法回退路径：在非强制场景保留 AES/SHA 套件，保证互操作与可用性。
常见误区：只改算法不改协议套件优先级，导致协商仍走国际算法；或只改服务端不改客户端信任库，导致握手直接失败。选型矩阵必须同时覆盖“算法—套件—证书—对端”四个维度，缺一不可。
综上，算法与协议选型的本质是把合规、互操作、性能、证书体系四个约束映射到具体套件参数上。矩阵的价值不在于列出所有组合，而在于让每一次替换都有明确的判断依据和回退方案。