信封加密：非对称只封钥匙，对称负责数据

全文分三层：

1. 通俗理解：把钥匙放进信封
2. 实际用处：云 KMS、PGP、HPKE、浏览器端加密
3. 原理与工程要点：ECDH + HKDF + AEAD 的完整流程、大文件分块、常见错误

第一层：通俗理解

1.1 把钥匙放进信封

你要寄一箱贵重物品给朋友：

1. 买一把新挂锁，把箱子锁上（对称加密数据，又快又能锁大东西）；
2. 把这把挂锁的钥匙放进一个只有朋友能拆的特制信封（用朋友的公钥加密这把小钥匙）；
3. 箱子和信封一起寄出。

朋友拆开信封拿到钥匙，再打开箱子。途中任何人都拿不到钥匙，也就打不开箱子。

1.2 为什么不直接用公钥加密整个文件

所以各取所长：非对称只负责那几十个字节的钥匙，对称负责剩下的一切。

第二层：实际用处

轮换主密钥变得很便宜：换主密钥时，只要把每个 DEK 重新封一次（每个只有几十字节），不需要把 TB 级的数据全部重新加密。这是云服务普遍采用信封加密的重要原因。

第三层：原理与工程要点

3.1 基于 ECDH 的完整流程

接收者事先生成一对长期密钥：私钥 $x$，公钥 $X = xG$。

发送方：

1. 生成一对临时密钥 $y$、$Y = yG$；
2. 计算共享秘密 $S = yX = xyG$（ECDH，见《Diffie–Hellman与离散对数》、椭圆曲线）；
3. 用 HKDF 从 $S$ 派生出对称密钥 $K$；
4. 用 AEAD（如 AES-GCM、ChaCha20-Poly1305）和随机 nonce 加密数据，得到密文和认证标签；
5. 发送 $(Y,\ \text{nonce},\ \text{密文})$。

接收方：用自己的私钥算 $xY = xyG = S$，派生出同一个 $K$，解密并验证标签。

只看到 $X$ 和 $Y$ 的旁观者，要算出 $xyG$ 就得解椭圆曲线离散对数问题。

3.2 为什么需要 HKDF

ECDH 得到的共享秘密 $S$ 是曲线上一个点的坐标，它不是均匀随机的比特串（比如它一定满足曲线方程），不能直接当 AES 密钥。HKDF 分两步：

• 提取（extract）：用 HMAC 把不均匀的输入"搅匀"成一个伪随机密钥；
• 扩展（expand）：结合 info 参数（如"某应用 v1 文件加密"）派生出所需长度的密钥。

info 参数还能做域分离：同一个共享秘密，给不同用途派生出互不相关的密钥。

3.3 为什么要 AEAD

只加密不认证是不够的：攻击者虽然读不懂密文，但可能改动它，让解密结果按他的意图变化（见《一次一密》 里的可延展性）。AEAD（带关联数据的认证加密）在加密的同时生成一个认证标签，密文被改动一个比特，解密就会直接失败。

3.4 大文件：分块加密

把一个几 GB 的录音一次性读进内存加密不现实。标准做法：

1. 随机生成一把内容密钥，用信封方式封起来；
2. 用这把内容密钥对文件分块做 AEAD，每块带序号，最后一块带"结束"标记；
3. 序号和结束标记防止攻击者重排、删除或截断数据块。

libsodium 的 secretstream 接口就是这样设计的，可以边录边加密。

3.5 常见错误

所以实践中最稳妥的选择是使用高层封装（libsodium 的 sealed box、HPKE 库、云 KMS 的 SDK），而不是自己拼装底层原语。

总结