一、为什么它快：同一把钥匙，同一条流水线

共享密钥加密（也称对称加密）的机制非常直白：

• 加密和解密用的是同一把密钥；
• 加密过程就是对数据逐块做一系列确定的算术与位运算（替换、置换、异或、移位）；
• 解密就是把这一串运算倒着做一遍。

所以它的速度只取决于"CPU 每秒能做多少次这样的运算"，跟数据内容无关——这就是它快的原因。今天主流 CPU 里甚至有专门为 AES 准备的硬件指令，一次能做完整的一轮运算。

对比一下就明白差距有多大：本章 5-3 要讲的公开密钥加密，一次运算要做几千次大数乘法，比对称加密慢三个数量级。这个速度差就是后来【混合加密】出现的唯一理由。

二、命门一：密钥空间有多大，就能撑多久

对称加密的强度完全由密钥长度决定——因为攻击者能做的只有一件事：把密钥试一遍。假设对手有一台每秒能试 10^12 个密钥的专用硬件，各长度分别能撑多久，Demo 里有完整的表。

记忆点在这里：DES 的 56 位在 1998 年就被专用硬件三天攻破——不是算法有洞，纯粹是钥匙太短。而 AES-256 的 2^255 次尝试，在宇宙年龄内都做不完。

三、命门二、三：分发问题与数量爆炸

对称加密真正的麻烦不是算得慢，而是这两条（下一节整节都在讲第一条）：

• 密钥分发：加密方和解密方必须先有同一把密钥。可"怎么把这把密钥安全地送到对方手里"本身就需要一条安全的通道——鸡生蛋。
• 数量爆炸：n 个人两两通信需要 n(n-1)/2 把密钥。10 个人 45 把，1000 个人 49.95 万把，而且每一把都要单独更换。

这一节先把这两个麻烦摆出来，是因为它们直接推导出了下一节的全部内容：公开密钥加密存在的意义，就是把这两个麻烦同时消掉。

四、动手 Demo：密钥空间，和一次"跟算法无关"的破解

# 一次性密码本：密钥和明文一样长，只使用一次
m1 = b"ATTACK AT DAWN"
m2 = b"DEFEND AT DUSK"
kx = b"KEYKEYKEYKEYKE"          # 两段明文共用了同一把密钥（错误做法）
c1 = bytes(a ^ b for a, b in zip(m1, kx))
c2 = bytes(a ^ b for a, b in zip(m2, kx))
x  = bytes(a ^ b for a, b in zip(c1, c2))   # 密钥在这一步被完全消掉

实跑输出：

一、密钥空间决定硬闯要多久（假设对手有每秒试 10^12 个密钥的专用硬件）
  密钥长度    举例                    平均要试      平均耗时
  56 位       DES（1977 年标准）      2^55          10.0 小时
  64 位       早期对称密码            2^63          106.8 天
  80 位       已不推荐                2^79          1.92 万年
  112 位      3DES 的有效强度         2^111         82.27 万亿年
  128 位      AES-128                 2^127         5.39e+18 年
  256 位      AES-256                 2^255         1.83e+57 年
  → 56 位只有 2^56 种，平均试一半就中——这就是 DES 倒下的根本原因：
     1997 年分布式互联网 5 个月、1998 年 EFF 的 Deep Crack 56 小时、
     1999 年两者合起来 22 小时 15 分。算法没错，是钥匙太短。

二、换长钥匙能不能一直加下去：能，但对称密码有个定理级的回答
  一次性密码本（密钥和明文一样长、只使用一次）在数学上不可破解——
  但【和明文一样长的密钥怎么安全送到对方手里】又绕回了分发问题。

三、密钥绝不能重复使用：一次 XOR 演示
  明文 1      ATTACK AT DAWN
  明文 2      DEFEND AT DUSK
  同一把密钥  KEYKEYKEYKEYKE
  密文 1      0a110d0a06126b040d6b01181c0b
  密文 2      0f001f0e0b1d6b040d6b010c180e
  把两段密文 XOR：051112040d0f0000000000140405
  → 密钥被完全消掉了：密文 1 XOR 密文 2 = 明文 1 XOR 明文 2
     只要我猜到其中一段明文（这里猜到是 ATTACK AT DAWN），
     另一段立刻还原：DEFEND AT DUSK
  → 结论：钥匙再好，重复使用就全废。这就是【一次一密】的由来。

四、DES 之后的路线：3DES 已经退场，AES 是当前答案
  算法            状况                  说明
  DES             已禁用                56 位，1998 年被短时间攻破
  3DES            已禁用                Sweet32 攻击；NIST 规定 2023 年底后停用
  AES-128/192/256 当前标准              2001 年 FIPS 197；有 CPU 硬件指令加速

五、量子计算机来了，对称密码只被【减半】，不会被击穿
  Shor 算法打的是 RSA/ECC（靠分解与离散对数）；对 AES 这类对称密码
  只有 Grover 算法，效果是平方根级别的加速，也就是有效强度减半：
  原始强度      量子下等效    判断
  AES-128       64 位         不够，要换
  AES-256       128 位        够用，仍是安全区
  → 所以 2026 年面对量子威胁的做法不是换掉 AES，
     而是【把长期要保密的数据从 AES-128 换成 AES-256】——一次配置改动。

读这个输出：

• 第一张表最该记住的是 56 位和 128 位之间的落差：10 小时对 5.39×10^18 年。密钥长度每加一位，攻击成本翻一倍——所以"钥匙加长一点"这事，效果是指数级的。
• 第三段那串十六进制最好亲手看一遍：0a110d0a... 和 0f001f0e... 异或之后变成 051112040d0f00...——注意后半段出现了连续的 00（因为两段明文在那些位置都含空格，20 XOR 20 = 00）。这正是"密钥被消掉"的可视化证据：结果里完全不包含密钥 KEYKEY… 的任何痕迹，只包含两段明文的关系。
• 第五段是本章唯一一个好消息：面对量子计算机，对称密码不需要换掉，只需要把钥匙加长——AES-256 在量子下等效于 128 位强度，仍然安全。要换的是 5-3 那种基于大数分解的方案。

五、⚠️ 2026 现状

• 【AES 用了二十多年，仍然是默认答案，而且看不到被替换的迹象】。 它 2001 年成为 FIPS 197 标准，今天的处理器普遍带 AES 硬件指令（AES-NI 一类），软件里几乎不必为此操心性能。选型上唯一要注意的是强度档位：长期需要保密的数据用 AES-256，一般场景 AES-128 仍然可用。
• 【老算法的退场是彻底而明确的】。 DES 早已禁用；3DES 因为 Sweet32 攻击（生日碰撞类攻击）在 NIST 规定里于 2023 年底后停用；RC4 也早已退场。在配置里看到这几个名字，可以直接判定为需要修改的历史遗留。
• 【实际事故很少是"算法被攻破"，绝大多数是"密钥用错了"】。 最常见的三种：用固定密钥或写死在代码里；同一把密钥重复使用（Demo 第三段那个演示）；密钥派生太弱（用口令直接当密钥、或不做加盐迭代）。这一点值得单独强调：换算法是配置问题，管好密钥是工程问题——后者才是真正的难点（5-7 里混合加密的存在，就是因为"每会话一把新密钥"这件事要靠工程手段落地）。
• 【量子带来的变化是"加长"，不是"换掉"】。 Grover 算法对对称密码只有平方根级别的加速，所以 AES-128 在量子下的有效强度降到 64 位（不够），AES-256 降到 128 位（够用）。这是一个很划算的结论：面对量子威胁，保护对称加密的代价只是"把 128 换成 256"——一次配置改动（详见 5-9）。

30 秒实验

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

1. 在命令行里查一下你电脑的 CPU 支不支持 AES 硬件加速（Linux 下 grep -o aes /proc/cpuinfo | head -1，Windows 下用 Get-CimInstance Win32_Processor | Select Name 看型号再查规格）；查不到也没关系，只要记住一句话：对称加密今天的瓶颈通常不在 CPU，而在网络和磁盘。
2. 拿两个数字感受一下"指数级"：56 位和 64 位只差 8 位，但破解时间从 10 小时变成 107 天（差约 256 倍）；128 位对比 256 位，差 128 位，破解时间差的就是 2 的 128 次方倍。这个"每加一位翻一倍"的直觉，是后面理解所有密钥长度选择的基础。

这一节要带走的一句是：共享密钥加密是密码学里最锋利的那把刀，但它只有一把钥匙——所以它所有的麻烦，都发生在"钥匙怎么送、怎么换"这两个动作上，而不在算法里。

常见误区

1. 错误：共享密钥加密和"共享密码"是一回事，都属于已经被淘汰的老办法。——纠正：这两件事完全无关，而且共享密钥加密今天仍是最主流的加密方式。你自己电脑上的硬盘加密、Wi-Fi 加密、以及每一次 HTTPS 连接里的实际数据传输，用的都是对称加密（5-7 会讲这个分工）。被淘汰的只是"用同一把密钥太多年、太短、还重复用"这种做法——不是这种技术本身。

2. 错误：既然 256 位更安全，那所有场景都应该用 AES-256。——纠正：要看数据需要保密多久、以及算力和带宽的成本。"保密期短的用 128、保密期长的用 256"是个务实的经验法则。更关键的是：在真实系统里，把 AES-128 换成 AES-256 常常不是瓶颈，把密钥生成、分发、轮换的流程做对才是。别把注意力放在一个不是短板的地方——这也是本章反复要绕回来的那个主题：密码学的失败很少发生在算法上。

3. 错误：一次性密码本在数学上不可破解，那就该用它。——纠正：理论安全不等于工程可用，它有两个致命前提：① 密钥必须和明文一样长——你要发 1 GB 的文件，就得先安全送出 1 GB 的密钥（"怎么送"又回到了分发问题）；② 密钥只能用一次，重复使用就会像 Demo 里那样瞬间崩塌。这两条叠加起来，意味着它只在极少数极端场景（比如元首级热线的密钥由专人递送）才可行。所以它今天是一个"理论上的上限"，不是"工程上的方案"——这也正好说明为什么现代对称加密的目标是"用一把短密钥，逼近一次性密码本的安全性"。

4. 错误：只要用了 AES，数据就是安全的。——纠正：AES 只是一个"加密原语"，它在真实系统里的安全性取决于周围那一圈工程细节。三个最典型的翻车点：① 密钥怎么产生（如果从口令直接派生、不加盐、不迭代，口令猜出来一切就完了）；② 分组模式选得对不对（老式的 ECB 模式会把相同明文块加密成相同密文块，图案会直接漏出来）；③ 密钥怎么保管（写死在代码或配置文件里，等于把钥匙贴在门上）。下面几节会依次解决其中的一部分：5-5 讲哈希与完整性，5-7 讲密钥怎么在会话里现生成。

• ☐ 下一节（5-3 解决密钥分发问题的密码）

相关笔记

• 密码学的历史 —— 上一篇：算法公开、只守密钥
• 解决密钥分发问题的密码 —— 下一篇：把"送钥匙"这个死结解开
• 索要赎金的计算机病毒 —— 同一个 AES，被用来锁死你的文件
• 实现安全的通信 —— 无线局域网加密里用的就是这一节的对称加密
• 🛡️ 网络与信息安全 · 索引 —— 全课路线图