加密算法选择策略：安全性、性能、兼容性
说到选加密算法，很多新人上来就问：「哪个算法最安全？」
这种问题我一般会反问一句：你打算用在哪儿？数据多重要？跑在什么硬件上？要跟谁通信？
其实没有万能算法。我经历过一个项目，团队统一用了 AES-256，觉得稳了。结果在低功耗 IoT 设备上跑，每次加解密要多花 80 毫秒，电池直接崩了。从此我明白：安全、性能、兼容性，三个维度必须一起看。
核心原则：用最短的密钥满足安全要求，用最快的算法满足性能预算，用最标准的实现保证互通。
安全性——没有的安全，只有足够长的密钥
安全性说白了就是「破解成本 > 数据价值」。我见过有人为了「心理安慰」用了 1024 位 RSA，其实 2048 位对绝大多数场景已经够用到 2030 年。
几个关键判断点：
- 对称加密：AES-128 至今未被有效破解；AES-192/256 更适合长期保存场景。
- 非对称加密：RSA 2048 是底线；ECC（如 secp256r1）在相同安全强度下密钥更短，性能更好。
- 哈希算法：SHA-256 已足够；SHA-1 千万别用了，我去年审计旧系统时还发现有人用 SHA-1 签名，直接红牌。
- 前向安全性：如果你做实时通信，优先选支持 DHE/ECDHE 的密码套件。
曾经有个坑：某版本 OpenSSL 默认使用 MD5 做证书签名，我们压测时一直报签名验证失败。你以为算法对了，但底层实现可能偷偷降级。用之前务必检查 OpenSSL 或 BoringSSL 的默认配置。
性能——每一毫秒都很宝贵
性能取决于三个因素：算法本身、密钥长度、硬件加速。我用 Python 做过一次简单压测，结果相当直观：
| 算法 | 密钥长度 | 加密 1MB 耗时 (ms) | 解密 1MB 耗时 (ms) | 建议场景 |
|---|---|---|---|---|
| AES-128-GCM | 128 bit | 0.8 | 0.8 | 高吞吐、Web API |
| AES-256-GCM | 256 bit | 1.2 | 1.2 | 敏感数据、长期存储 |
| ChaCha20-Poly1305 | 256 bit | 0.9 | 0.9 | 移动端、无 AES 加速的 CPU |
| RSA-2048 (OAEP) | 2048 bit | 45 | 1.5 | 密钥交换、小数据加密 |
| Ed25519 | 256 bit | 0.2 | 0.2 | 签名、认证 |
你想想看，RSA 加密比解密慢 30 倍，而且是独占 CPU 的。所以实际项目中我一般只用 RSA 做密钥封装，不用它加密大块数据。
还有一个细节：GCM 模式比 CBC 快，而且自带认证标签，能防填充攻击。我现在所有新项目都只用 GCM 或 ChaCha20-Poly1305，CBC 基本淘汰了。
小技巧：在 x86 设备上 AES-NI 指令集能把 AES 加速 5-10 倍。如果服务器 CPU 支持（2010 年后基本都支持），一定要在编译时开启 -maes 或使用官方驱动。
兼容性——别让你的算法成为孤岛
兼容性这个词听着不高大上，但翻车率最高。我曾经在跨国项目中选了 SM4（中国国密），结果欧美客户的旧浏览器根本不支持，最后不得不在网关层做算法转换，多写了一堆胶水代码。
几个必须检查的点：
- 标准合规：FIPS 140-2/140-3 认证的算法（如 AES、SHA-256、RSA）在所有主流平台都有实现。
- 平台支持：OpenSSL 1.1.1 以上支持所有常见算法；BoringSSL 少一些；自己写的加密库千万别碰。
- 数据格式：常见的 PEM、DER、JWK、PKCS#12 格式是否都支持？我见过有人用 raw bytes 传 RSA 公钥，结果对方解析器不认。
- 互操作性测试：如果买第三方服务（如云 HSM），一定先跑通端到端加解密再上线。
| 场景 | 推荐算法 | 兼容性备注 |
|---|---|---|
| 通用 Web API | AES-256-GCM + ECDHE | TLS 1.3 默认套件 |
| 移动端离线存储 | ChaCha20-Poly1305 | Android/iOS 原生支持 |
| 企业 PKI / CA | RSA 2048 + SHA-256 | 所有 CA 和浏览器都支持 |
| 国密场景 | SM2/SM3/SM4 | 需要专用库（如 GmSSL） |
| 区块链 / 分布式 | Ed25519 / secp256k1 | 大多数链原生支持 |
如何权衡三个维度？
我的决策流程是这样的：
- 确定数据敏感等级：普通日志？用户密码？金融交易？不同等级对应最低安全强度。
- 评估硬件/网络预算：CPU 主频？是否有硬件加速？网络带宽是否受限？
- 列出必须兼容的系统：对方用 OpenSSL 1.0.2？Java 8？浏览器？这个列表直接砍掉一批算法。
- 在交集里选性能最优的：通常 AES-256-GCM 是安全且性能不错的「万金油」；如果设备太弱就退到 ChaCha20-Poly1305。
下面这张图是我自己项目里经常贴在白板上的决策框架：
回到实际项目，我一般先用这个框架筛选出 2-3 个候选，然后写一段小的基准测试：
from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
import os, time
def bench_aes_gcm(data, key):
iv = os.urandom(12)
cipher = Cipher(algorithms.AES(key), modes.GCM(iv))
encryptor = cipher.encryptor()
start = time.perf_counter()
encryptor.update(data) + encryptor.finalize()
return (time.perf_counter() - start) * 1000
data = b'x' * (1024 * 1024) # 1MB
key_128 = os.urandom(16)
key_256 = os.urandom(32)
print(f"AES-128-GCM: {bench_aes_gcm(data, key_128):.2f} ms")
print(f"AES-256-GCM: {bench_aes_gcm(data, key_256):.2f} ms")跑完之后，你心里就有底了。比如在高并发场景，AES-128-GCM 比 256 快 30% 但安全强度只差一级，完全可以接受。而在金融合规场景，必须走 256 位，那你就得接受这个性能开销。
经验之谈：别在开发环境中「感觉」哪个算法快。你的电脑和服务器差距很大，一定要在生产环境的硬件上压测至少 3 轮取中位数。
最后补一句：无论你最终选了什么算法，加密库版本也得盯紧。我记得 OpenSSL 1.0.2 有个 Padding Oracle 漏洞，升级到 1.1.1 才修复。这事在团队里发生过一次，我后来专门写了个 CI 脚本检查所有依赖的加密库版本，低于安全基线直接阻断构建。