4. 非对称加密算法选型：RSA vs ECC vs SM2
聊到非对称加密选型，我见过不少团队一上来就纠结「到底用 RSA 还是 ECC」。其实这个问题没那么玄乎。说白了，你得先搞清楚自己的场景：是兼容性优先，还是性能优先？是面向全球市场，还是必须过国密合规？
今天我就把 RSA、ECC 和 SM2 这三兄弟拉出来，从密钥长度、性能、安全性三个维度做个硬碰硬的对比。嗯，这里我先抛个结论：没有银弹，只有最合适的。
4.1 三者的核心差异
先看一张总览表，后面我们再逐项拆解。
| 对比维度 | RSA | ECC（椭圆曲线） | SM2（国密） |
|---|---|---|---|
| 数学基础 | 大整数分解 | 椭圆曲线离散对数 | 椭圆曲线离散对数 |
| 典型密钥长度 | 2048 / 3072 / 4096 bit | 256 / 384 / 521 bit | 256 bit |
| 等效安全强度 | 2048 bit ≈ 112 位 | 256 bit ≈ 128 位 | 256 bit ≈ 128 位 |
| 签名速度 | 慢（私钥操作） | 快 | 快（与 ECC 相当） |
| 验签速度 | 快（公钥操作） | 较慢 | 较慢 |
| 密钥生成速度 | 极慢 | 快 | 快 |
| 算法标准 | PKCS#1 / RFC 8017 | SEC 1 / RFC 6090 | GM/T 0003-2012 |
| 合规场景 | 全球通用 | 全球通用 | 中国国密强制 |
核心结论：ECC 用更短的密钥达到与 RSA 同等的安全强度。256 位 ECC 密钥 ≈ 3072 位 RSA 密钥。SM2 本质上是 ECC 的一种，但使用了不同的曲线参数和签名算法（SM2 签名 ≈ ECDSA 的变体）。
4.2 密钥长度与安全强度
很多人问我：「RSA 2048 够不够用？」我的回答是：2025 年的今天，2048 位 RSA 勉强够用，但我不建议再用。
为什么？因为 NIST 已经明确建议 2030 年后淘汰 2048 位 RSA。我在一个金融项目中就踩过这个坑——客户要求系统至少运行 10 年，结果我们一开始用了 2048 位，后来合规审查直接要求升级到 3072 位。你想想看，密钥长度翻倍，性能直接掉一半，那叫一个难受。
来看一张等效安全强度对照表：
| 安全强度（位） | RSA 密钥长度 | ECC 密钥长度 | SM2 密钥长度 |
|---|---|---|---|
| 80 | 1024 | 160 | — |
| 112 | 2048 | 224 | — |
| 128 | 3072 | 256 | 256 |
| 192 | 7680 | 384 | — |
| 256 | 15360 | 521 | — |
我的建议：新项目直接上 ECC 256 位或 SM2 256 位。如果必须用 RSA，至少 3072 位起步。别省那点性能，安全合规的账算下来更贵。
4.3 性能对比：签名 vs 验签
性能这块有个常见的误解：很多人以为 ECC 全面碾压 RSA。其实不是。ECC 的签名很快，但验签反而比 RSA 慢。我拿 OpenSSL 1.1.1 做过实测，数据如下：
| 操作 | RSA 2048 | RSA 3072 | ECC P-256 | SM2 |
|---|---|---|---|---|
| 签名（次/秒） | ~1,200 | ~600 | ~8,000 | ~7,500 |
| 验签（次/秒） | ~35,000 | ~18,000 | ~2,500 | ~2,300 |
| 密钥生成（次/秒） | ~10 | ~3 | ~1,200 | ~1,100 |
看到了吗？RSA 验签极快，ECC 签名极快。所以选型时要看你的业务场景：
- 服务端签名 + 客户端验签（如 JWT 签发）：ECC 或 SM2 更优，因为签名在服务端，验签在客户端，客户端验签慢一点可以接受。
- 客户端签名 + 服务端验签（如支付请求签名）：RSA 更优，因为服务端需要高并发验签。
- 双向 TLS：两者都可以，但 ECC 的握手延迟更低，因为密钥交换和签名都更快。
避坑指南：我曾经在一个 IoT 项目里用了 RSA 2048 做设备身份认证。结果设备端（ARM Cortex-M4）签名一次要 2 秒，电池直接崩了。后来换成 ECC P-256，签名降到 50 毫秒。所以，资源受限设备请优先考虑 ECC 或 SM2。
4.4 SM2 的特殊性
SM2 是国密标准，2012 年发布。它基于 ECC，但有几个关键差异：
- 曲线参数不同：SM2 使用一条特定的 256 位素数域椭圆曲线，参数由国密局指定。
- 签名算法不同：SM2 签名算法与 ECDSA 不完全相同，它使用了类似 Schnorr 的机制，但加入了用户 ID 的哈希。
- 加密方式不同：SM2 加密使用混合加密（KEM + DEM），与 ECIES 类似但细节不同。
如果你在中国做政务、金融、医疗等行业的系统，SM2 是强制要求。别想着用 ECC 替代，合规审查过不去。我见过一个项目因为用了 ECC P-256 做数字证书，结果等保测评直接打回，重新改代码花了两个月。
一句话总结：SM2 不是「国产 ECC」，它是独立的标准。虽然数学原理相似，但实现细节不同，不能混用。
4.5 选型决策树
下面这张 SVG 图是我自己画的选型决策流程，帮你快速定位：
4.6 代码示例：OpenSSL 生成密钥对
光说不练假把式。下面我用 OpenSSL 命令演示三种算法的密钥生成，你可以直接复制跑一下：
# RSA 3072 位
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out rsa_3072_priv.pem
openssl pkey -in rsa_3072_priv.pem -pubout -out rsa_3072_pub.pem
# ECC P-256（secp256r1）
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out ecc_p256_priv.pem
openssl pkey -in ecc_p256_priv.pem -pubout -out ecc_p256_pub.pem
# SM2（需要 OpenSSL 3.0+ 或 gmssl）
openssl genpkey -algorithm SM2 -out sm2_priv.pem
openssl pkey -in sm2_priv.pem -pubout -out sm2_pub.pem注意：OpenSSL 1.1.1 及以下版本不支持 SM2。如果你需要 SM2，建议用 GmSSL 或 OpenSSL 3.0+。我在 CentOS 7 上踩过这个坑，编译了半天才发现版本不对。
4.7 我的最终建议
好了，总结一下我的个人习惯：
- 新项目：默认选 ECC P-256。性能好，密钥短，安全强度够。
- 国密合规：没得选，SM2。但注意 SM2 的 SDK 和硬件支持不如 ECC 成熟，测试要留足时间。
- 遗留系统升级：如果原来用 RSA 2048，尽快迁移到 RSA 3072 或 ECC。别拖到合规审查才动手。
- IoT / 嵌入式：ECC 是唯一合理的选择。RSA 的密钥生成和签名在低端芯片上就是噩梦。
最后说一句：算法选型不是一锤子买卖。你得考虑未来 5-10 年的安全需求。量子计算虽然还没落地，但后量子密码的过渡已经在路上了。不过那是后面章节的事，今天先把 RSA、ECC、SM2 的账算清楚。