📚 课程目录第3章加密算法选择

3. 加密算法选择：对称与非对称算法对比、选型建议

加密算法选型这件事，说白了就是在速度和安全之间找个平衡点。我做SDK性能调优时，经常遇到有人上来就选RSA-4096，结果压测发现CPU烧到90%，业务方直接炸毛。所以这一节咱们把对称和非对称算法掰开揉碎了讲清楚，再给出一套可落地的选型建议。

3.1 对称加密：快，但密钥是命门

对称加密，就是加密和解密用同一把密钥。你想想看，就像你家大门钥匙，既能开也能锁。优点是快，非常快，硬件加速后AES-256-GCM在单核上能跑到几个GB/s。我曾在对象存储场景里做过压测，AES-256-GCM比RSA-2048快了至少三个数量级。

AES：硬件指令集（AES-NI）加持下性能无敌，128位密钥安全等级够用，256位更稳。
ChaCha20：没有AES-NI的老CPU上表现更好，流模式，抗侧信道攻击更强。
SM4：国标算法，国内合规必选，性能与AES-128接近。

我的习惯：只要目标平台有AES-NI，我无脑选AES-256-GCM。既满足机密性+完整性，还省去了单独的MAC计算。

3.2 非对称加密：安全门槛高，但慢得让人心疼

非对称加密，公钥加密私钥解密，或者私钥签名公钥验签。优点是密钥分发方便，但计算开销大。举个例子，RSA-2048加密1KB数据，耗时大约是AES-256的几百倍。这就导致你不能拿它去加密文件本身——扛不住。

算法	典型密钥长度	加密速度	解密/签名速度	安全性（等效对称）
RSA	2048/4096位	慢（～1MB/s）	极慢（～0.1MB/s）	AES-128 / AES-256
ECC（椭圆曲线）	256位（P-256）	比RSA快3~5倍	比RSA快2~3倍	AES-128
SM2	256位	与ECC相近	与ECC相近	AES-128
Ed25519	256位	签名快	验签极快	AES-128

我曾经踩过的坑：在一个IoT项目里直接用RSA加密每个传感器数据包，结果服务端解密队列堆积到几万，最终整个系统崩溃。后来改成混合加密才救回来。

3.3 混合加密：现实世界的最优解

你不可能在对象存储里用RSA加密每个对象——就算CPU扛得住，延迟也超标。实际做法是：用非对称加密保护对称密钥，用对称加密保护数据。这就是混合加密，也叫信封加密。

流程很简洁：客户端生成一个随机的对称密钥（比如AES-256），用它加密数据；再用服务端的公钥加密这个对称密钥。服务端收到后，先解密对称密钥，再用它解密数据。这样既解决了密钥分发，又享受了对称加密的高性能。

# 伪代码：信封加密流程（Python风格）
from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
from cryptography.hazmat.primitives.asymmetric import rsa, padding
import os

# 1. 生成随机的对称密钥（DEK）
data_key = os.urandom(32)

# 2. 用DEK加密实际数据（AES-256-GCM）
nonce = os.urandom(12)
cipher = Cipher(algorithms.AES(data_key), modes.GCM(nonce))
encryptor = cipher.encryptor()
ciphertext = encryptor.update(plaintext) + encryptor.finalize()
# 3. 用服务端公钥加密DEK（RSA-OAEP）
public_key = load_public_key()
encrypted_key = public_key.encrypt(
    data_key,
    padding.OAEP(
        mgf=padding.MGF1(algorithm=hashes.SHA256()),
        algorithm=hashes.SHA256(),
        label=None
    )
)
# 4. 上传 (ciphertext + nonce + tag + encrypted_key)

结论：对象存储加密SDK几乎都采用混合加密。
我参与过的商业SDK里，密钥协商和封装部分归非对称管，实际数据传输全交给对称加密。选型时不需要纠结“用什么加密”，而是要盯着密钥生成开销和底层库的硬件加速。

3.4 选型决策树：一张图说清楚

下面这张SVG图把选择路径画出来了，你对着自己场景一步步走就行。

3.5 实战选型清单

结合我多年的调优经验，给你列几条硬标准，直接照着选：

数据量大（对象存储场景） → 必须用对称加密，首选AES-256-GCM。如果要在无AES-NI的ARM芯片上跑，切ChaCha20。
密钥协商/数字签名 → 用ECC（P-256）或SM2，不要再用RSA-2048了。ECC性能好、密钥短，而且对TLS握手延迟影响小。
合规要求 → 国内选SM2+SM4，等保三级以上必须国密。
性能瓶颈在哪？ → 用perf看看CPU热点，对称加密通常不在热点里（因为有AES-NI），反而是签名验签、公钥操作容易成为瓶颈。

避坑指南：我曾经手抖把RSA私钥当成DEK去加密对象，结果一个1MB对象加密花了3秒。所以一定要记住：非对称只加密小数据（≤256字节），大数据交给对称。

3.6 小结：别纠结，先看量级

对称加密快如闪电，非对称加密稳如泰山，但都不能一条腿走路。在实际的对象存储加密SDK里，你只需要记住一个公式：数据量 > 1KB → 对称；密钥交换 & 签名 → 非对称。选型时优先考虑硬件加速支持（AES-NI / SM4-NI），其次看密钥长度和算法安全余量。我把这个决策树贴在墙上，每次选型直接走一遍，从没出过问题。