波仔
🛡️ 第五章 什么是密码、数字签名、数字证书
📄 一句话概括

混合加密就是让两种加密各干自己擅长的事：用公开密钥加密送一把临时生成的对称密钥，之后所有数据走对称加密——速度靠对称，密钥分发靠公开密钥，HTTPS 里的 SSL/TLS 从头到尾就是这么干的。

📝 本节和前面几节的关系

到这里两种加密都讲完了，而它们的优缺点正好互补：5-2 的对称加密快，但钥匙难送；5-3 的公钥加密钥匙好公开，但慢三个数量级。

这一节就是把两者拼起来——本章之后的所有内容（HTTPS、SSH、VPN、邮件加密）用的都是这个组合结构，它们之间只差"密钥怎么协商、身份怎么验证"这两件事的细节。

一、先把速度差实测出来：为什么不能"一路 RSA 到底"

这不是一个理论问题，而是可以直接量出来的差距（Demo 第一段是本机实测）：

结果就是：用 RSA 直接加密 1 MB 需要约 2.3 分钟，而用对称加密只要约 2.4 毫秒——差约 5.8 万倍。这个差距足以解释为什么真实系统里没有任何一处会"全程用公钥加密"。

二、混合加密：五步结构

混合加密（hybrid encryption）的流程非常固定：

  1. 临时随机生成一把对称密钥（比如 32 字节，只给这一次会话用）；
  2. 用这把临时密钥加密全部数据（快）；
  3. 用对方的公钥加密这把临时密钥（只有 32 字节，公钥运算一次就够）；
  4. 把【被公钥加密的临时密钥 + 被对称密钥加密的数据】一起发出去；
  5. 对方先用私钥取出临时密钥，再用它解数据。

两个关键设计值得单独点出来：

三、动手 Demo：实测速度差与握手流程

import random, time, hashlib

n, m = (1 << 2047) | 1, random.getrandbits(2000)
dd = random.getrandbits(2048) | 1

t0 = time.perf_counter()
for _ in range(200): pow(m, dd, n)          # RSA 私钥运算
rsa_ms = (time.perf_counter() - t0) / 200 * 1000

data = b"x" * (1024 * 1024)
t0 = time.perf_counter()
for _ in range(200): hashlib.blake2b(data, digest_size=32).digest()   # 对称路径
sym_ms = (time.perf_counter() - t0) / 200 * 1000

blocks = (1024 * 1024) // 245               # RSA 一次只能 245 字节
print("RSA 加密 1 MB 预计 %.1f 秒" % (blocks * rsa_ms / 1000))
print("对称加密 1 MB %.2f 毫秒" % sym_ms)

实跑输出：

一、先测两种运算的真实速度差（本机实测）
  一次 RSA-2048 私钥运算（解密或签名）        约 32.81 毫秒
  对称密码处理 1 MB 数据（用 BLAKE2b 代测速度量级）约 2.41 毫秒
  → 单次运算慢了约 14 倍（真实 AES 有 CPU 指令加速，差距还要更大）

  那用 RSA 直接加密 1 MB 会怎样？RSA 每次最多只能处理 245 字节，
  1 MB 要切成 4279 块，每块做一次模幂：
  预计耗时            2.3 分钟（对称加密同样 1 MB：约 2.41 毫秒）
  → 慢了约 58284 倍。这就是【不能一路 RSA 到底】的硬理由。

二、混合加密：各干各擅长的活
  ① 临时随机生成一把【对称密钥】（32 字节，只给这一次会话用）
  ② 用这把临时密钥加密全部数据（快）
  ③ 用对方的【公钥】加密这把临时密钥（只有 32 字节，RSA 一次就够）
  ④ 把【RSA 加密的临时密钥 + 对称加密的数据】一起发出去
  ⑤ 对方先用私钥取出临时密钥，再用它解数据
  → 速度靠对称，密钥分发靠公钥，两边的好处都拿到。

三、TLS 握手就是这套流程的真实实现
  步      发生了什么
  1       客户端打招呼：我支持哪些版本与算法组合
  2       服务器回：用哪个组合 + 自己的服务器证书（含公钥）
  3       客户端验证书（验到根）、双方算出一把共享的会话密钥
  4       之后全部数据用会话密钥做对称加密
  5       会话结束，这把临时密钥丢弃

四、前向保密：为什么临时密钥用完就丢
  · 老写法（TLS 1.2 里的 RSA 密钥交换）会把会话密钥用服务器的
     长期私钥加密传过去——服务器私钥一旦泄露，历史流量全部能被解开
  · TLS 1.3 已删除 RSA 密钥交换，只保留每次会话现算的临时密钥
  · 结果：今天录下的流量，即使明年服务器私钥泄露，也解不开
  · 2026 现状：TLS 1.3 占加密流量的约 66%~78%，
     TLS 1.2 只剩约 2.7%~6%，TLS 1.0/1.1 已被所有主流浏览器禁用

读这个输出：

四、⚠️ 2026 现状

30 秒实验

今天做两个动作，各 15 秒：

  1. 在浏览器的开发者工具里打开任意 https 站点，看"安全"标签页：找到"连接"或"协议"这一栏，看清它写的是 TLS 1.3 还是 1.2。如果是 1.3，说明你的浏览器和这个网站都已经在"删掉旧零件"的那一侧了。
  2. 看一次握手的耗时：在开发者工具的"网络"面板里，把某条 https 请求点开，看"连接"或"TLS"这一段花了多少毫秒。再想想如果这是一个跨洲访问（延迟 200 毫秒）、页面要开 30 个第三方连接，握手省下的那一个往返会累积成多少——这就是 TLS 1.3 把握手压到一个往返的实用价值。

这一节要带走的一句是：混合加密的巧妙之处不在于发明了新算法，而在于让两种已有算法各自只做自己最擅长的那一小段——真正难的部分（密钥分发）交给慢但可靠的那个，剩下的体力活交给快得几乎免费的那个。

常见误区

  1. 错误：HTTPS 就是用 RSA 加密网页内容。——纠正：HTTPS 里真正加密网页内容的不是 RSA，而是对称加密。RSA（或 ECDHE）只用来在握手里协商出一把会话密钥，之后的所有数据都走对称加密——因为"用 RSA 加密 1 MB"在本机实测里要 2.3 分钟，而对称加密只要 2.4 毫秒。 理解这一点有个实际用处：你不会再以为"换个更强的公钥算法就能提升网页加载速度"——恰恰相反，公钥算法的选择是为了安全强度与握手数据量，速度上真正的杠杆在对称算法和 TLS 版本。

  2. 错误：会话密钥用完就丢，没什么意义。——纠正："用完就丢"是前向保密的全部内容，而且它保护的是历史。如果不丢（老式的 RSA 密钥交换就是把会话密钥用服务器长期私钥加密传过去），那么服务器私钥一旦泄露，攻击者可以把过去录下来的所有流量一起解开。"用完就丢"切断了这条回溯链：今天的密钥泄露，只影响这一刻之后的连接。 在一个"流量可以被长期录音存储"的环境里，这个性质的价值比"多一层加密"高得多（5-9 里"先存后解"的威胁，正是针对这个性质来的）。

  3. 错误：既然混合加密已经这么成熟，那加密这件事就不用操心了。——纠正：混合加密保护的是"传输的那一段路"，出了这段路就管不到了。三个常见的盲区：① 服务器解密之后数据是明文的——数据库里怎么存、谁能访问、日志里有没有漏出去，全都要另外设计；② 元数据通常不加密——谁和谁通信、什么时候、流量多大，这些看得见（5-11 会讲邮件里的这个现象）；③ 端点上如果是恶意软件，加密也帮不上忙——数据在你的屏幕上就是明文的。一句话：加密是必要的一层，不是全部。

  4. 错误：TLS 1.2 还那么多人用，说明它还够用。——纠正："还在用"和"够用"是两件事，而且时间表已经定了。TLS 1.2 的设计年份是 2008 年，它的密码套件里仍然保留了 3DES、RC4 这类已经退场的零件，前向保密需要额外配置，这些年为了修补降级攻击（BEAST、POODLE、DROWN、ROBOT）花了很多力气。 关键日期：Apple 2026 年 12 月从信任库移除 TLS 1.2 信任；Chrome／Edge 2027 年第一季度默认禁用。升级 TLS 1.3 只是配置改动（不需要重签证书），所以现在把配置改过来，成本远低于等到 2027 年被动挨打。

自测三问（点开对答案） 1. 混合加密里，为什么公钥加密的"慢"变得不重要了？ —— **因为它被限制在一个极小的载荷上**。**公钥运算在整个流程里只处理 32 字节的会话密钥，它的耗时是个固定的几十毫秒量级**，**而真正的大数据全部走对称加密**。**本机实测清楚地展示了这个分工的收益**：**用 RSA 直接处理 1 MB 要 2.3 分钟，而对称加密只要 2.4 毫秒**——**如果把公钥加密的慢限制在 32 字节上，那几十毫秒的开销在一次连接里完全可以接受**（而且握手的这笔开销还会被连接复用摊薄，5-8 会提到）。**这就是"用架构解决问题，而不是用算法解决问题"的典型例子。** 2. "前向保密"到底保护了什么？没有它会怎样？ —— **它保护的是【过去的通信记录】**。**没有前向保密的做法（把会话密钥用服务器长期私钥加密传过去）意味着：所有历史会话的密钥，都能被服务器这把长期私钥解开**——**于是一旦私钥泄露，攻击者可以把过去攒下的全部录音一次性解密**。**有前向保密之后，每次会话用一把现算现丢的临时密钥**，**私钥泄露只能影响"泄露之后"的连接**。**这个性质在一个"流量可以被长期批量录音存储"的时代里非常关键**——**因为攻击的成本结构变了：解密一次历史流量，远低于重新攻击一个已修复的系统。** 3. 为什么后量子迁移在协议层也用"混合"的做法？ —— **因为混合能同时防两类风险**。**只用新算法，风险是"它太新，可能藏着还没被发现的弱点"**；**只用老算法，风险是"量子计算机成熟后会被解开"**。**混合密钥交换把两者都跑一遍、结果合并成会话密钥**——**要攻破必须同时攻破两个，等于"取两者的最大强度"**。**还有一个现实考虑是兼容性**：**混合方式让新旧系统仍能协商出可用的密钥**。**浏览器数据显示这种做法已经大面积铺开**（**客户端支持率 69.94%**），**而服务器侧只有 9.37%**——**这也说明迁移的关键工作正在服务器与 CDN 配置那一侧。**

相关笔记