3. 非对称加密在存储中的应用：RSA、ECC 用于密钥交换与数字信封
聊到非对称加密在存储里的角色，我个人的看法是：它从来不是用来直接加密大块数据的。为什么？太慢了。你想想看，一个 1TB 的硬盘，如果用 RSA 逐块加密，那性能基本没法看。那它到底干嘛用？说白了，就是管钥匙的。
我在项目中遇到过好几次这样的场景：客户要求所有存储数据必须加密，但又要支持多用户共享访问。如果每个用户都拿同一把对称密钥，那密钥分发就是个噩梦。这时候，非对称加密就派上用场了——它负责安全地传递那把真正用来加密数据的对称密钥。
3.1 RSA：老牌劲旅，但要注意用法
RSA 的安全性基于大整数分解的困难性。给你两个大素数 p 和 q，乘起来得到 n 很容易，但给你 n 让你反推出 p 和 q，那就难了。这就是 RSA 的数学根基。
在存储系统中，RSA 最常见的用法就是密钥封装。举个例子：
# 伪代码：RSA 密钥封装流程
# 发送方
对称密钥 = AES-GCM-256 随机生成()
加密后的数据 = AES-GCM-Encrypt(明文数据, 对称密钥)
加密后的密钥 = RSA-Encrypt(对称密钥, 接收方的公钥)
# 接收方
解密后的密钥 = RSA-Decrypt(加密后的密钥, 接收方的私钥)
解密后的数据 = AES-GCM-Decrypt(加密后的数据, 解密后的密钥)
核心要点：RSA 只加密小数据块（通常不超过密钥长度），真正的大数据加密交给对称算法。这就是所谓的"混合加密"模式。
嗯，这里要注意一个坑。RSA 的填充方案很重要。我曾经见过一个项目，直接用教科书式的 RSA（没有填充），结果被选择密文攻击打得体无完肤。我个人习惯用 OAEP（Optimal Asymmetric Encryption Padding），它在 PKCS#1 v2.2 里定义得清清楚楚。
| RSA 填充方案 | 安全性 | 推荐场景 |
|---|---|---|
| PKCS#1 v1.5 | 中等（有已知攻击） | 兼容旧系统 |
| OAEP | 高（IND-CCA2 安全） | 新系统首选 |
| 无填充 | 低（仅用于测试） | 绝对不要在生产环境用 |
避坑指南：我曾经接手过一个遗留系统，RSA 密钥长度只有 1024 位。在 2024 年的今天，这已经不够安全了。我建议新系统至少用 3072 位，保守点直接上 4096 位。别为了省那点计算时间，把整个系统的安全底线给降了。
3.2 ECC：更小的钥匙，更强的保护
ECC（椭圆曲线密码学）是 RSA 的有力竞争者。它的核心优势在于：同等安全强度下，密钥长度短得多。256 位的 ECC 密钥，安全性和 3072 位的 RSA 差不多。这意味着什么？更少的存储开销，更快的计算速度。
我建议你在存储系统中优先考虑 ECC，尤其是当你有大量密钥需要管理的时候。举个例子，一个云存储网关可能要管理上百万个用户密钥，用 ECC 能省下不少空间。
ECC 在存储中的典型应用是密钥协商。最经典的协议是 ECDH（Elliptic Curve Diffie-Hellman）：
# 伪代码：ECDH 密钥协商
# Alice 和 Bob 各自生成密钥对
Alice: (dA, QA) # 私钥 dA，公钥 QA
Bob: (dB, QB) # 私钥 dB，公钥 QB
# 交换公钥后，各自计算共享密钥
Alice: 共享密钥 = dA * QB
Bob: 共享密钥 = dB * QA
# 结果：两人得到相同的共享密钥，但窃听者无法计算
个人经验：我在做分布式存储系统时，用 ECDH 来做节点间的会话密钥协商。每次新节点加入集群，只需要交换一次公钥，后续所有通信都能用派生的对称密钥加密。这比每次重新生成 RSA 密钥对要高效得多。
3.3 数字信封：把两种加密结合起来
数字信封（Digital Envelope）这个概念，说白了就是非对称加密包着对称加密。它解决了存储系统中最实际的问题：既要安全地传输密钥，又要高效地加密数据。
我画了一张图，帮你理清数字信封的完整流程：
数字信封在存储系统中的典型应用场景包括：
- 安全文件传输：发送方用接收方的公钥加密对称密钥，只有持有对应私钥的接收方才能解开
- 密钥管理服务（KMS）：KMS 用主密钥（非对称）来加密工作密钥（对称），实现密钥的层级保护
- 数据共享：同一份数据加密后，可以用不同用户的公钥分别加密对称密钥，实现多用户访问
我建议：在实际项目中，数字信封的"信封"部分（加密后的密钥）可以和密文一起存储。比如在文件头里放一个字段，专门存放加密后的对称密钥。这样文件本身就是自包含的，接收方拿到文件就能解密，不需要额外的密钥数据库。
3.4 RSA vs ECC：怎么选？
这个问题我经常被问到。我的回答是：看场景。下面这个表格是我根据多年经验整理的选型参考：
| 对比维度 | RSA | ECC |
|---|---|---|
| 安全强度（等效） | 3072 位 ≈ 128 位对称 | 256 位 ≈ 128 位对称 |
| 密钥生成速度 | 慢（需要找大素数） | 快（随机数生成） |
| 加密/解密速度 | 加密快，解密慢 | 两者都快 |
| 签名速度 | 慢 | 快 |
| 密钥存储开销 | 大（3072 位 = 384 字节） | 小（256 位 = 32 字节） |
| 兼容性 | 极好（几乎所有平台支持） | 好（现代平台都支持） |
| 推荐场景 | 旧系统兼容、小数据量加密 | 新系统、高性能要求、IoT 设备 |
避坑指南：我曾经在一个嵌入式存储项目里用了 RSA，结果密钥生成花了整整 30 秒，设备启动时间完全不可接受。后来换成 ECC，密钥生成几乎是瞬时的。所以，如果你的系统对启动时间或响应时间有要求，我强烈建议优先考虑 ECC。
3.5 实践中的注意事项
最后，分享几个我在实际项目中踩过的坑，希望能帮你少走弯路：
- 密钥生命周期管理：非对称密钥对也有有效期。我建议定期轮换，比如每 90 天换一次。别让一把私钥用上好几年。
- 私钥存储：私钥必须加密存储。我见过有人把私钥明文放在配置文件里，那跟没加密一样。用 HSM（硬件安全模块）或者至少用密码加密的 PKCS#12 文件。
- 随机数质量：非对称加密对随机数质量要求极高。别用 rand()，用 /dev/urandom 或者专门的加密随机数生成器。
- 侧信道攻击：在云环境或共享硬件上，要注意时序攻击和缓存攻击。我建议使用常数时间实现，比如 OpenSSL 的常量时间 RSA 实现。
好了，关于非对称加密在存储中的应用，核心就是这些。记住一句话：非对称加密管钥匙，对称加密管数据。把这两者结合起来，你就能构建出既安全又高效的存储加密方案。