4. 数据传输加密：对称加密（AES-GCM）、非对称加密（RSA/ECC）、混合加密方案

聊到数据传输加密，我见过不少团队一开始就陷入「用什么算法」的选择困难症。其实说白了，加密这件事就三个核心问题：怎么保证只有对方能看懂？怎么安全地交换密钥？怎么兼顾速度和安全性？ 这一章，我们就把这几个问题彻底讲透。

4.1 对称加密：AES-GCM 为什么是首选？

对称加密，就是加密和解密用同一把钥匙。你想想看，就像你和你朋友共用一把锁，谁都能锁也能开。优点是快，特别快；缺点嘛——钥匙怎么安全地交给对方？

目前业界公认的对称加密标准是 AES（Advanced Encryption Standard）。我个人习惯用 AES-256-GCM，为什么？因为它不光加密，还顺带做了完整性校验。

核心要点：AES-GCM 是「认证加密」模式，同时提供机密性、完整性和真实性验证。一次操作，三个保障。

AES 的几种模式对比

模式 特点 适用场景 我的评价
ECB 简单，但相同明文块产生相同密文 基本不用 ❌ 千万别用，有严重安全缺陷
CBC 需要 IV，串行加密 文件加密 ⚠️ 能用，但要注意 IV 随机性
CTR 可并行，无填充 流式数据 ✅ 不错，但缺认证
GCM CTR + GMAC 认证，AEAD 网络传输、TLS ✅ 强烈推荐

我曾经在一个 IoT 项目里踩过坑——用了 AES-CBC 加密传感器数据，结果没做消息认证，中间人篡改了密文，服务端解密后得到一堆乱码，还以为是设备故障。后来换成 GCM，一次搞定加密和认证，再没出过类似问题。

我的小技巧：使用 AES-GCM 时，IV（初始向量）必须是唯一的，长度推荐 12 字节。千万别重复使用同一个 IV，否则加密就形同虚设。

AES-GCM 代码示例（Python）

from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import os

# 生成 256 位密钥
key = AESGCM.generate_key(bit_length=256)
aesgcm = AESGCM(key)

# 加密
nonce = os.urandom(12)  # 12 字节 IV
plaintext = b"这是需要加密的敏感数据"
ciphertext = aesgcm.encrypt(nonce, plaintext, None)

# 解密
decrypted = aesgcm.decrypt(nonce, ciphertext, None)
print(decrypted.decode())  # 输出：这是需要加密的敏感数据

4.2 非对称加密：RSA 与 ECC 的抉择

非对称加密，说白了就是两把钥匙——公钥加密，私钥解密。公钥随便给人看，私钥自己藏好。这样密钥分发的问题就解决了。

目前主流的两大阵营是 RSA 和 ECC（椭圆曲线加密）。我个人的经验是：新项目优先选 ECC，原因很简单——同样的安全强度，ECC 的密钥短得多，计算也快。

算法 密钥长度（同等安全强度） 性能 推荐场景
RSA-2048 2048 位 慢（尤其私钥操作） 兼容旧系统、数字签名
ECC P-256 256 位 快（约 RSA 的 10 倍） 移动端、IoT、新系统
ECC Curve25519 256 位 极快，抗侧信道攻击 密钥交换（首选）

注意：RSA 的密钥长度不能太短。1024 位 RSA 已经被破解，现在至少要用 2048 位。而 ECC 用 256 位就能达到同等安全级别，差距一目了然。

我记得有一次帮一个金融客户做 API 安全加固，他们还在用 RSA-1024。我直接建议升级到 ECC P-384，虽然迁移成本有点高，但安全团队评估后认为值得。嗯，从那以后他们的安全审计再没出过问题。

非对称加密的典型用途

  • 密钥交换：用 ECDH（椭圆曲线 Diffie-Hellman）协商对称密钥
  • 数字签名：用 ECDSA 或 RSA-PSS 验证身份和完整性
  • 加密小数据：比如加密对称密钥本身（RSA 最多加密密钥长度减去开销的数据）

4.3 混合加密方案：取长补短

你可能会问：既然非对称加密能解决密钥分发问题，为什么不全用非对称？原因很简单——慢。非对称加密比对称加密慢几百到上千倍。所以实际应用中，我们用的是混合加密。

混合加密的思路其实很朴素：用非对称加密来安全地传递对称密钥，然后用对称加密来加密实际数据。 这样既解决了密钥分发问题，又保证了加密速度。

混合加密的标准流程：

  1. 客户端生成一个随机的对称密钥（比如 AES-256 密钥）
  2. 用服务器的公钥（RSA 或 ECC）加密这个对称密钥
  3. 把加密后的对称密钥发送给服务器
  4. 服务器用私钥解密，得到对称密钥
  5. 双方用这个对称密钥进行 AES-GCM 加密通信

实际项目中的混合加密方案

我参与过一个医疗数据传输项目，要求端到端加密。我们用的方案是：

  • 密钥交换：ECDH（Curve25519）协商出共享密钥
  • 数据加密：AES-256-GCM
  • 身份认证：Ed25519 签名

为什么这么选？因为医疗数据量大，对称加密必须快；同时要保证密钥交换的安全性和前向安全性（即私钥泄露后，历史通信仍然安全）。ECDH 配合临时密钥对，正好满足这个需求。

避坑指南：我曾经见过一个团队自己实现混合加密，结果把对称密钥直接拼在密文前面，还没加密。嗯，这相当于把家门钥匙放在门口脚垫下面。正确的做法是：对称密钥必须用接收方的公钥加密后再传输。

4.4 知识体系总览

下面这张图把本章的核心逻辑串起来了。你可以看到数据从发送方到接收方，经历了怎样的加密旅程。

数据传输加密方案总览 混合加密方案流程图 发送方 生成 AES 密钥 用公钥加密密钥 AES-GCM 加密数据 发送 网络传输 加密后的对称密钥 + AES-GCM 加密数据 （中间人无法解密） 接收方 用私钥解密密钥 AES-GCM 解密数据 获取原始明文

4.5 总结与最佳实践

说了这么多，最后给你几个我多年总结的铁律：

  1. 数据加密永远用对称加密，首选 AES-256-GCM
  2. 密钥交换用 ECDH（Curve25519 或 P-256），别自己发明协议
  3. 身份认证用数字签名，Ed25519 或 ECDSA
  4. 永远不要用 ECB 模式，永远不要重复使用 IV
  5. 混合加密是标准做法，TLS 就是这么干的

最后一句忠告：别自己实现加密算法。用成熟的密码学库，比如 OpenSSL、libsodium、Bouncy Castle。我在代码审查中见过太多「自制加密」的惨案了——嗯，没有一个能通过安全审计的。

← 上一章 📖 返回目录 下一章 →