加密算法与GDPR：AES、RSA、ECC在个人数据保护中的应用

加密这事儿，在 GDPR 合规里到底有多重要？

我直接说吧：如果数据泄露了，而你用了强加密，监管机构大概率不会开罚单。反过来，明文存储一泄露，基本就是百万欧元起步。我在几个欧洲客户的 DPO 项目里，见过太多因为没选对加密算法而被迫整改的案例。所以这章咱们就扎进算法本身，看看 AES、RSA、ECC 到底该怎么用在个人数据保护上。

为什么加密是 GDPR 的“免死金牌”

GDPR 第 32 条要求“采用适当的技术措施”。第 34 条又说：如果数据被加密且密钥安全，个人数据泄露可能“不太可能对自然人权利和自由造成风险”。说白了，加密做对了，连通知用户的义务都能豁免。你想想看，这多值钱。

但注意——不是随便用一个算法就行的。我记得有个项目，客户用 DES 加密身份证号，我还以为看错了……DES 早就被 NIST 废弃了，那加密等于没用。监管机构一眼就能识破。

GDPR 下加密的三大目标：
  • 机密性——只有授权方才能看到明文。
  • 完整性——数据没被篡改。
  • 可问责性——你能证明加密措施到位。

AES：个人数据静态加密的首选

AES（高级加密标准）是对称加密，加密和解密用同一把密钥。速度极快，硬件支持也好。我在做 GDPR 审计时，几乎每个客户的数据存储层都在用它。AES-256 是行业标配，连美国 NSA 都用它保护绝密级信息。

适用场景：

  • 数据库中的敏感字段（姓名、地址、银行账户）
  • 备份文件和日志
  • 磁盘加密（LUKS、BitLocker）
我的习惯：对个人数据做列级加密时，我会选 AES-256-GCM——它自带认证标签，能防篡改。用 CBC 模式也行，但必须搭配 HMAC 做完整性校验，否则容易被 padding oracle 攻击。我以前踩过这个坑，后来就再也不用 CBC 了。

代码示例（Python 使用 PyCryptodome）：

from Crypto.Cipher import AES
from Crypto.Random import get_random_bytes

key = get_random_bytes(32)  # AES-256
cipher = AES.new(key, AES.MODE_GCM)
plaintext = b"personal_data"
ciphertext, tag = cipher.encrypt_and_digest(plaintext)
# 存储时：cipher.nonce + tag + ciphertext

RSA：安全的密钥分发与数字信封

对称加密有个老大难问题：密钥怎么传给对方？RSA 就是解决这个的。用接收方的公钥加密 AES 密钥，接收方用私钥解密，之后再用 AES 加密数据。这叫做“数字信封”。

但 RSA 慢，而且密钥越长性能越差。GDPR 场景下，我一般只拿它做密钥交换，不用它直接加密大数据。

适用场景：

  • 安全的密钥传输（API 调用、邮件附件）
  • 数字签名（证明数据来源和完整性）
  • 小数据块的直接加密（如令牌或凭证）
曾经踩过的坑：我记得有个项目用了 RSA-1024，觉得够用了。结果几年后 NIST 直接建议最低 2048 位，1024 位的密钥对已经被暴力破解过一些测试用例。我当时只好全部轮换。所以——现在起步至少 2048，我个人建议直接上 4096。

代码示例（使用 cryptography 库）：

from cryptography.hazmat.primitives.asymmetric import rsa, padding
from cryptography.hazmat.primitives import serialization, hashes

private_key = rsa.generate_private_key(public_exponent=65537, key_size=2048)
public_key = private_key.public_key()

# 加密 AES 密钥
aes_key = get_random_bytes(32)
cipher_aes_key = public_key.encrypt(
    aes_key,
    padding.OAEP(mgf=padding.MGF1(algorithm=hashes.SHA256()), algorithm=hashes.SHA256(), label=None)
)

ECC：用更小的密钥达到同等安全

椭圆曲线密码（ECC）是 RSA 的现代替代品。256 位的 ECC 密钥安全性与 3072 位的 RSA 相当。对移动端和 IoT 设备来说，这简直是救命。GDPR 合规里，很多跨国数据流动需要在传输层握手用 ECDHE 密钥交换。

适用场景：

  • TLS 证书（P-256 或 P-384 曲线）
  • 移动 App 端到端加密
  • 签名和密钥协商
我的建议：如果你从零构建系统，直接上 ECC。曲线选 Curve25519（用于密钥交换）和 Ed25519（用于签名）。它们没有专利限制，实现也经过了充分验证。我在一个金融科技项目里用 X25519 做 ECDH，性能和安全性都很满意。

三种算法的核心对比

特性 AES RSA ECC
加密类型 对称 非对称 非对称
主要用途 数据加密 密钥交换 / 签名 密钥交换 / 签名
密钥长度（等效） 256 位 2048–4096 位 256–384 位
性能 极快 慢（尤其解密） 快（尤其签名）
GDPR 适配度 存储加密首选 密钥分发必用 传输层主流
典型轮换周期 1 年 2–3 年 2–3 年
加密算法与 GDPR 个人数据保护——应用映射 数据生命周期 收集 / 传输 静态存储 密钥管理 推荐算法 TLS (ECDHE) ECC P-256 列级加密 AES-256-GCM 密钥封装 RSA-4096 为什么要这样组合？ • 传输阶段：ECDHE 用 ECC 密钥交换 + TLS，前向安全。 • 存储阶段：AES-256-GCM 加密每行数据，密文与认证标签一起存。 • 密钥管理阶段：用 RSA-4096 公钥加密 AES 密钥，私钥离线保存。 • 三者互补，覆盖数据从收集到销毁的全生命周期。

各算法在 GDPR 审计中的举证要点

审计的时候，监管机构想看的不是“你用了 AES”，而是“你怎么证明你用的 AES 是合规的”。我个人经验，下面这几点必须准备好：

  1. 算法版本与模式——你别只是写“AES”，要写明 AES-256-GCM，附上 NIST 标准号。
  2. 密钥长度——RSA 必须≥2048，ECC 必须≥256，AES 必须≥128（我推荐 256）。
  3. 密钥生命周期——生成、分发、存储、轮换、销毁，每个环节都要有文档。
  4. 随机数质量——使用 CSPRNG，不能依赖 Math.random()。
  5. 证书或 SKI——非对称密钥要有 X.509 证书或 Subject Key Identifier 记录。
我曾经被审计问倒的一件事：对方问“你的 RSA 公钥是如何分发的？有完整性保护吗？”我说“我们通过 HTTPS 下载的”。审计员接着问：“那如何保证下载到的公钥没被篡改？”——我答不上来。后来我们加上了密钥指纹校验和离线签名。记住：公钥分发也必须是安全渠道。

实战中的算法选择建议

不用纠结哪个算法最好。它们是搭配使用的，不是二选一。我个人习惯这么规划：

  • 数据在路（transit）： TLS 1.3 + ECDHE (X25519) + AES-256-GCM
  • 数据在库（rest）： AES-256-GCM 加密每个敏感字段，主密钥用 RSA-4096 或 KMS 包装
  • 数据在用（use）： 严格尽量少，如果必须运算，考虑可信执行环境

嗯，这里要注意：如果未来你考虑量子安全，ECC 可能会被 SIDH 或 Dilithium 替代，但那是后话了。现阶段，上面这个组合足够通过任何 GDPR 审计。

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