一、什么叫"加密的危殆化"

危殆化（compromise）指的是：一个算法曾经被认为安全，后来因为攻击手段进步或计算力变便宜，而不再安全了。 这件事在密码学史上发生过很多次，而且每一次都不是"突然崩塌"，而是"安全余量一点点被吃掉"。

这张表最重要的一列不是"现状"，而是中间那一列——它告诉你每一个算法是"从哪个方向倒下的"，而倒下方向决定了你能不能救它。

危殆化从三个方向来，三个都要盯着：

注意第三个来源最容易被忽略：前两个是"算法本身的问题"，第三个是"代码写错了"。Heartbleed 出现在 OpenSSL 这个被全世界用的库上，而它不是数学被攻破，是一个边界检查漏了——这类问题不会因为"换个更长的密钥"而消失。

一句话结论：换算法不是【出了事才做】，而是【到期就得做】的例行维护。

二、证书出事之后：五种吊销做法与它们的毛病

证书为什么会"出事"？ 最常见的四种情况：私钥泄露了（服务器被入侵，攻击者拿到了私钥）、域名易主了（公司把域名卖了，旧证书还在有效期内）、CA 误签了（签给了不该签的人）、用户主动注销了（员工离职、设备报废）。

5-4 讲的证书链验证回答的是"这张证书是不是可信 CA 签的"，但它回答不了"这张证书今天还有效吗"。 后者就需要另一套机制——吊销。

历史上和现在一共有五种做法，各有各的坑：

OCSP 曾经被寄予厚望，因为它"实时"。但它最后退场了，原因有两条：

• 隐私：你用 OCSP 查一张证书，CA 就立刻知道你正在访问哪个网站、来自哪个 IP。哪怕 CA 主观上不记录，也可能被要求交出——这等于把"你去过哪儿"这份记录，交给了第三方。
• 性能与成本：Let's Encrypt 高峰时每月处理约 3400 亿次 OCSP 请求，相当于每秒 14 万次。这份资源用来做别的事更值得。

而所有吊销机制有一个共同的、更根本的毛病：软失败（soft-fail）。 意思是：查不到就放行。

为什么浏览器要这么"不负责任"？ 因为反过来更糟：如果"查不到就拒绝"，那么 CA 的 OCSP 服务器一挂，全世界一半网站立刻打不开。两害相权，浏览器宁可放行。

结论：吊销机制在现实中【不可靠】，不能当作唯一保险。

三、动手 Demo：一份算法退役清单与一张吊销对照表

下面这段直接跑出来的输出，等于把上面的道理做成了可核对的事实——注意最后两段，它解释了为什么行业放弃"靠吊销"，转而去做一件看起来更笨的事。

一、危殆化 = 昨天还称得上安全的算法，今天不能再用了
  算法        怎么倒下的                                    现状
  DES         56 位密钥，1998 年被 3 天攻破                 已禁用
  MD5         2004 年找到碰撞，可伪造文件与证书             已禁用
  SHA-1       2017 年 SHAttered 实际碰撞                    已弃用
  RC4         输出有统计偏差，可恢复明文                    已禁用
  3DES        Sweet32 攻击；NIST 2023 年底后停用            已禁用
  RSA-1024    计算力足够后可直接分解                        已禁用

二、危殆化的三个来源（都要盯着）
  来源                  举例
  数学被攻破            MD5、SHA-1 的碰撞；未来量子计算机对 RSA/ECC
  计算力变便宜          DES 的 56 位在 1998 年就被专用硬件拿下
  实现有洞              Heartbleed（读走服务器内存）、填充预言攻击
  → 换算法不是【出了事才做】，而是【到期就得做】的例行维护。

三、证书吊销：五种做法的分工
  机制                谁去查                时效            2026 状况
  CRL（吊销列表）     客户端下载整个列表    每 4~7 天       强制保留，CA 必须发布
  OCSP（在线查询）    每次连接都去问 CA     实时            正在退场
  OCSP Stapling       服务器替客户端去问    实时            推荐开启
  CRLite / CRLSets    浏览器内置压缩列表    本地查          Firefox 137 起全量
  CT（证书透明度）    谁都能查签发记录      签发时          主流浏览器强制

四、为什么 OCSP 会退场（Let's Encrypt 于 2025-08-06 关停）
  · 隐私：你用 OCSP 查一张证书，CA 就立刻知道你正在访问哪个网站、
     来自哪个 IP。哪怕 CA 主观上不记录，也可能被要求交出。
  · 性能与成本：Let's Encrypt 高峰时每月处理约 3400 亿次 OCSP 请求，
     相当于每秒 14 万次——这份资源用来做别的事更值得。
  · 对策：吊销信息没有消失，只是换了通道——改由 CRL 发布，
     浏览器侧则靠 CRLite 这类内置压缩列表本地判断。

五、吊销机制的根本毛病：软失败（soft-fail）
  场景                          多数浏览器的实际行为
  OCSP 服务器超时/被墙          放行（不然网络一抖全网不能访问）
  CRL 下载不到                  放行
  证书确实已被吊销              可能照常显示挂锁
  → 结论：吊销机制在现实中【不可靠】，不能当作唯一保险。

六、于是业界的解法变成：不靠吊销，靠【让证书很快就过期】
  时间                  公开信任的 TLS 证书最长有效期 续期压力
  2026-03-15 之前       398 天                        每年约 1 次
  2026-03-15 起         200 天                        每年约 2 次
  2027-03-15 起         100 天                        每年约 4 次
  2029-03-15 起         47 天                         每年约 7~8 次
  · 一张证书只活 47 天，私钥泄露能造成的暴露窗口就天然很短，
     不必再指望【吊销】这个环节能不能及时生效。
  · 代价是要上自动化：100 张证书在 47 天周期下约 800 次续期/年，
     手工按每次 2 小时算就是约 1600 工时——手工方案在这里直接失效。
  · 域名验证信息的复用时限同步收紧：2029 年起只剩 10 天。

四、真正的解法：不靠吊销，靠让证书很快就过期

把上面最后一段的逻辑讲透，因为它是一个"用设计绕开管理难题"的漂亮例子。

思路的转变是这样的：

• 旧思路：证书有效期长一点省事（398 天），出事了我再吊销。问题是吊销不可靠（软失败），等于把希望寄托在一个"多半不会生效"的机制上。
• 新思路：把"有效期"本身当成安全手段。一张证书只活 47 天，那么即使私钥今天泄露了，攻击者能用它的时间也最多 47 天——"最短暴露窗口"成了一个天然属性，不再依赖任何人类操作。

代价是什么？是运维必须自动化。

这张表其实在说一件很实在的事：它把一个"技术问题"翻译成了"工时问题"。100 张证书在 47 天周期下约 800 次续期/年，手工按每次 2 小时算就是约 1600 工时——按一个人一年 2000 个工时算，差不多是养一个人专门续证书。所以 2026 年"有证书"的门槛里，已经悄悄多了一条：你得有自动化（这正是 5-4 里域名验证信息复用时限收紧到 10 天的同一个原因）。

顺带解释了 5-4 留下过的一个疑问：为什么证书有效期一直在缩短？就是因为"吊销"这条路被证明走不通，行业只能走"短命证书"这条路。

一句话记住：短有效期不是"麻烦"，而是把"事后补救"换成"天然止损"。

五、⚠️ 2026 现状

1. 危殆化不再是历史课，已经有了官方日历。 NIST IR 8547 明确把 RSA-2048、ECDSA、ECDH 的弃用定在 2030 年、禁用定在 2035 年——也就是说，"到期就得换"这件事已经从经验上升为可排期的工程计划（对照 5-9 的 CNSA 2.0 节点，军工和政府侧的时间表更紧）。

2. 吊销的路线已经定了：CRL 留下，OCSP 退场。 CA/Browser Forum Ballot SC-063（2023-07 通过、2024-03-15 生效）把 OCSP 改为可选、CRL 改为强制（吊销后 24 小时内必须发布新 CRL）；Let's Encrypt 从 2025-05-07 起签发的证书不再包含 OCSP 网址，并于 2025-08-06 正式关停 OCSP 服务。浏览器侧则改用本地压缩列表：Chrome 的 CRLSets 约 600 kB、只覆盖约 3.5 万条（约占全部 400 万条的 1%），把最主要的吊销事件挡在门外；Firefox 137 起用 CRLite 下发全量吊销集。

3. 短有效期成为行业主策略。 SC-081v3 的三阶段（200 天 → 100 天 → 47 天）已经排好，Let's Encrypt 另有一套更激进的计划：2027-02-10 降到 64 天、2028-02-16 降到 45 天（域名验证信息的复用时限先降到 10 天、再降到 7 小时）。2023 年还批准了一种"7 天内有效"的短命证书——它短到不需要任何吊销机制，因为它几乎不会在有效期内出事。

4. 真正贵的一步是"盘点"，不是"替换"。 2026 年最现实的困难是：大量设备里嵌着 RSA-2048，而且升不了级——工控设备、IoT 传感器、老的 VPN 网关、已经停产的网络设备。这也是迁移路线图要按系统类别给不同截止日的原因（软件签名与 TLS 最先、IoT 与工控最后）。换句话说，危殆化考验的不只是"你能不能换算法"，更是"你知不知道自己有哪些东西在用旧算法"——这一点和 4-9 的漏洞诊断是同一件事：先看清资产，才谈得上处置。

30 秒实验

1. 量一次证书的有效期。 打开任意一个网站，点地址栏的挂锁图标 → 「证书」→ 找到「生效日期」和「到期日期」，把两个日期相减。2026 年新签的证书多数在 90~200 天之间；如果你看到 397 天左右，说明这张证书是 2026-03-15 之前签发的（那时上限还是 398 天）。再顺手看一眼「颁发者」——如果整条链是同一个 CA，说明这个站点没有使用中间证书加固。

2. 让同一个文件被两种算法各算一次。 在 Windows 上打开 PowerShell，敲：

Get-FileHash C:\Windows\System32\notepad.exe -Algorithm MD5 Get-FileHash C:\Windows\System32\notepad.exe -Algorithm SHA256

你会看到第一个结果是一串 32 位十六进制，第二个是 64 位。 再看一眼上面那张退役清单：MD5 那一行写的是"已禁用"——注意它禁用的是什么场合：不是"不能用来算校验值"，而是"不能再用它来判断文件有没有被篡改"，因为任何人改了文件之后，都能重新算出一个让旧 MD5 对上的版本。这也是为什么下载页面上贴的校验值现在是 SHA-256 开头的那一串。

常见误区

1. 错误：算法被淘汰，是因为它当初设计错了。——纠正：DES、MD5、SHA-1 在设计时都没有明显的低级错误，它们是被"安全余量被吃光"击倒的。MD5 甚至到今天都没有出现"能对任意文件造成碰撞"的实际攻击——它是被"选前缀碰撞"击倒的：2020 年的一项工作只花了约 4.5 万美元的 GPU 租金，就伪造出了让 MD5 对上的 PGP 签名。所以判断标准不是"有没有被破"，而是"安全余量还剩多少"——这也解释了为什么官方的弃用日期总是比"实际攻破"早很多年。

2. 错误：证书被吊销了，浏览器就一定会拦住。——纠正：多数浏览器在查不到吊销信息时选择放行，这就是软失败（soft-fail）。所以吊销是"尽力而为"，不是"保证生效"——它的可靠性取决于 OCSP 服务器今天通不通、CRL 今天下不下载得到。真正的保证来自短有效期，不来自吊销。

3. 错误：让证书很快过期是多此一举，反正有吊销。——纠正：短有效期的意义在于把"事后补救"变成"天然止损"。一张只活 47 天的证书，私钥泄露能造成的暴露窗口就天然很短，不必再指望"吊销能不能及时生效"这个不确定的环节。代价是必须上自动化：100 张证书约 800 次续期/年、手工约 1600 工时，这个量级的手工方案在数学上就行不通。

4. 错误：危殆化是运维的事，跟我的系统设计没关系。——纠正：危殆化会反过来改设计要求，这就是"算法敏捷"（crypto agility）。它要求你把"用哪个算法、多长的密钥"做成可替换的一处配置，而不是硬编码在几十个模块里——2026 年的后量子迁移之所以被认为难，一半难点就在这里：不是"新算法不好用"，而是"旧算法撒得太开，找不到全部调用点"（对照 4-12：组件依赖越多，这种盘点就越难做）。

• ☐ 下一节（5-11 增强电子邮件的安全性）

相关笔记

• 安全性更高的加密 —— 上一节：算法会老，以及量子带来的整类替换
• 增强电子邮件的安全性 —— 下一篇：把加密与签名用到一个具体场景上
• 公开密钥加密的核心技术 —— 证书链验证回答"可不可信"，吊销回答"今天还有效吗"
• 实现安全的通信 —— WEP → WPA → WPA3 的演变，是同一套"危殆化与替换"逻辑
• 🛡️ 网络与信息安全 · 索引 —— 全课路线图