3. 常见加密算法：AES、RSA、ECC 与国密 SM2/SM4
聊到应用层加密，算法选型是绕不开的一步。我个人习惯把算法先分成两类：对称加密和非对称加密。搞清楚了这两类，SDK 的代码结构基本就定了一半。
3.1 对称加密：AES 与 SM4
对称加密，说白了就是加密和解密用同一把钥匙。你想想，快递柜的取件码就是典型的对称密码——输入同一串数字，门开了。
AES（高级加密标准）是国际公认的对称加密标杆。我在项目中遇到过最坑的事，就是有人把 AES 的密钥硬编码在 APK 的 so 文件里，反编译一下就直接看到了。嗯，这里要注意：AES 本身没问题，问题全在密钥管理。
| AES 模式 | 是否需要 IV | 安全性 | 典型场景 |
|---|---|---|---|
| ECB | 否 | 低（同一明文块输出相同） | 不推荐，仅兼容遗留系统 |
| CBC | 是 | 较高 | 文件加密、数据库字段 |
| GCM | 是 | 高（附带认证） | 网络传输、API 响应加密 |
| CTR | 是 | 较高 | 流式数据、实时通信 |
SM4 是国家密码管理局发布的对称加密标准，它的密钥长度也是 128 位，分组大小和 AES 一样。你可能会问，那干嘛不直接用 AES？原因很简单：合规。金融、政务、关键基础设施的系统，现在明文要求必须用国密。SM4 在算法强度上不输 AEs，但国内的硬件和软件生态对它的优化还在追赶。
3.2 非对称加密：RSA 与 ECC
非对称加密用一对钥匙——公钥加密，私钥解密。你想想看，把公钥公开给所有人，大家都能给你发加密消息，只有你能解开。这在密钥分发上解决了对称加密的“配送难题”。
RSA 是我最早接触的非对称算法。它的安全性依赖于大整数分解的数学难题。1024 位的 RSA 现在已经不安全了，行业标准是 2048 位。我曾经在物联网项目里用 2048 位 RSA，结果设备 CPU 跑一次签名用了 800 毫秒，老板直接问“你是不是在给用户做进度条动画？”
ECC（椭圆曲线加密） 用更短的密钥达到相同安全级别。比如 256 位的 ECC 相当于 3072 位的 RSA。为什么会这样？椭圆曲线上的离散对数问题目前还没有高效破解办法。我在移动端 SDK 设计里，只要条件允许，会优先选 ECC 做签名和密钥协商，性能开销小很多。
| 算法 | 密钥长度（安全级别 128 位） | 签名耗时（参考值） | 主要瓶颈 |
|---|---|---|---|
| RSA | 3072 位 | ～5ms（私钥签名） | 密钥生成慢、密文膨胀 |
| ECC | 256 位 | ～1ms | 曲线参数选择复杂 |
| SM2 | 256 位 | ～1.2ms | 国产硬件加速有限 |
3.3 国密算法：SM2 / SM4 / SM3
国密系列不是一套单独的名字，而是一套完整的密码体系。包括对称加密 SM4、非对称加密 SM2、哈希 SM3。为什么单独拎出来讲？因为国内监管对这部分有强制要求，而且它们在设计上与国际标准有差异。
- SM2：基于椭圆曲线，公钥 64 字节，私钥 32 字节。它的签名算法和 ECDSA 不同，验签时必须使用国密标准的派生函数。我在对接某地方银行时，对方要求 SM2 签名必须用
sm2sign-with-sm3模式，而不是随便传个摘要进去。 - SM4：前面讲过了，注意模式选择。
- SM3：国密哈希算法，输出 256 位。它的压缩函数和 SHA-256 不同，但安全性相当。SM3 在国密体系里用来做消息认证和 SM2 签名的摘要。
3.4 这些算法在 SDk 里怎么选？
选型不是拍脑袋，我一般按这个决策链条来走：
- 先看合规要求：客户或监管是否强制国密？是，直接上 SM2 + SM4 + SM3。
- 再看运行环境：目标平台安全芯片有硬件加速吗？AES-NI 指令集可让加解密快 10 倍。如果没有，考虑 ECC 和 SM2 也能接受。
- 然后看传输模式：短数据交互（比如握手、令牌交换）用非对称；长数据（响应体、大文件）用对称。
- 最后看密钥生命周期：记住，算法只是安全链条的一环。密钥存哪、怎么轮换，比选哪个算法更重要。
好了，这就是加密算法的基础认知。每种算法都有它的脾气——AES 快但管理密钥麻烦，RSA 安全但是吃性能，ECC 和 SM2 很省资源但得注意参数合规。你实际开发时，别光看算法名字，还要看它被封装成什么样子。我在下一步会带你看，SDK 内部是怎么把这些算法组装成可调用的 API 的。