3.1 对称密钥密码的工作原理

3.1 对称密钥密码的工作原理

本节摘要：对称密码用同一把密钥完成加密与解密，是速度最快、部署最广的加密形态——AES 在现代 CPU 的硬件指令加持下吞吐量以每秒吉字节计。本节厘清它的模型、性能来源与适用边界，并把它的死穴"密钥分发"量化出来：n 方全互联需要 n(n-1)/2 把密钥，这个二次增长正是第 4 章公钥革命的引信。

先约定一把共同的钥匙

对称密码的模型一句话可以说完：发送方与接收方持有同一把密钥，加密与解密是同一算法的一对互逆操作。这与古典密码一脉相承——凯撒移位的移位量、维吉尼亚的密钥词、恩尼格玛的日钥，全是对称密钥；现代分组密码 AES 与流密码 ChaCha20 也全是对称密钥。名字里的"对称"指的是密钥关系，不是算法形状。

它统治数据加密的理由只有一个字：快。DES 与 AES 的轮函数全部由查表、异或、移位、模加这类 CPU 最擅长的原子操作构成，AES 甚至被做进了 Intel 与 AMD 芯片的硬件指令集（AES-NI），单核吞吐量达到每秒数吉比特量级——加密一部高清电影的计算开销可以忽略不计。这就是为什么 TLS 握手协商出会话密钥之后，真正承载数据的是对称算法：非对称运算只负责"把会话密钥安全地送到位"，重活全部交给对称密码（这个分工的完整故事在第 4、6 章展开）。

图：密钥分发困境——全互联的密钥数按平方爆炸

二、分发困境的两条历史出路与未竟之路

平方爆炸逼出了两条经典出路。其一是密钥分发中心（KDC）：每人只与中心共享一把主密钥，任意两人通话前由中心临时签发会话密钥——密钥总量从 n(n-1)/2 降回 n，代价是中心成为性能瓶颈与头号攻击目标；麻省理工八十年底开发的 Kerberos 协议至今仍是企业内网的这一路线代表。其二是手工预共享：点对点场景（如企业间专线）由管理员人工配置密钥，可控但完全无法扩展到开放互联网——你没法用快递把密钥送给一个刚认识的网站。

两条路都没触及根本。真正的出路要等 1976 年：Diffie 与 Hellman 指出"协商一把共同密钥可以不需要任何秘密信道"——那一页论文开启了第 4 章的公钥革命。但在翻开新篇章之前，需要先把对称密码这半个大厦的地基打完：钥匙是怎么在两个系统之间分发下去的（本节），钥匙指挥下的分组变换内部长什么样（3.2 节），一长串数据如何被切成块逐块加密（3.3 节），密钥流式掩码的另一步棋（3.4 节），以及光保密不认证为什么等于半裸（3.5 节）。

下面的代码用一个以哈希函数造密钥流的玩具方案演示对称流程的骨架——加密与解密互为镜像，密钥决定一切：

import hashlib

def keystream(key: bytes, length: int) -> bytes:
    """用哈希链造密钥流：H(key||counter) 逐块拼接（演示用，非标准方案）"""
    stream = b""
    counter = 0
    while len(stream) < length:
        stream += hashlib.sha256(key + counter.to_bytes(8, "big")).digest()
        counter += 1
    return stream[:length]

def xor_bytes(a: bytes, b: bytes) -> bytes:
    return bytes(x ^ y for x, y in zip(a, b))

key = b"session-key-42"                      # 双方事先共享的对称密钥
msg = "拂晓渡河".encode("utf-8")

ct = xor_bytes(msg, keystream(key, len(msg)))  # 加密：明文异或密钥流
pt = xor_bytes(ct, keystream(key, len(msg)))   # 解密：再异或一次，互为镜像
print(ct)        # 一串与明文长度相同的伪随机字节
print(pt.decode("utf-8"))                      # -> 拂晓渡河
​

异或的自反性让加解密共用同一段代码——这正是对称二字的形状。但注意这段代码并不安全（密钥流对同一密钥重复），3.3 与 3.4 节会解释标准化方案如何避免这类陷阱。

⚠️ 常见误解："算法越强越安全，密钥怎么管无所谓"。工程事故的统计结论恰好相反：绝大多数对称加密被攻破的案例，问题出在密钥硬编码进源码、跨环境复用、过期不轮换这类管理疏漏，而不是算法本身被攻破。

常见问答

问：用两把不同密钥加密两次，是不是安全一倍？多数情况下不是。分组密码的两次加密存在中间相遇攻击——先对第一段穷举建表，再对第二段反向穷举撞表，成本远低于密钥长度直接相加，3DES 双密钥版约 112 位的实际强度正是这样算出来的。

问：口令能直接当对称密钥用吗？不能。口令是人类记忆的产物，熵值通常远低于密钥要求，且分布可猜。正确做法是经专用的密钥派生函数加盐慢散列，把口令拉伸成密钥，6.3 节的信封示例就是这个形状。

问：初始向量要不要保密？不要。它只需不可预测且不重复，随密文明传即可；需要保密的只有密钥本身。把向量的职责与密钥混淆，是初学者最常见的配置错误之一。

问：同一把密钥能既做加密又做认证吗？不建议直接复用。加密密钥与认证密钥应从主密钥分别派生，某一路出问题不至全线失守——AEAD 构造的内部已经替你做了这件事。

对称密码的三条适用边界

边界一，身份问题：对称密钥只能证明"持有同一把钥匙"，无法在多用户环境里区分"谁在用"，需要认证还得配合公钥体系或额外的凭证体系。边界二，分发时序：密钥必须先于第一次通信到达，任何"先通信后补密钥"的设计都绕不开公钥协商。边界三，抗抵赖：双方持有同一把密钥意味着任何一方都能伪造另一方的消息，无法向第三方归责——这正是数字签名（4.5 节）存在的理由。记住三条边界，对称与公钥的分工就不再需要死记硬背。

本节要点回顾

• 对称模型：同一把密钥加解密互逆，从凯撒到 AES 一脉相承；
• 性能地位：轮函数由查表、异或、移位构成，配合 CPU 硬件指令可跑出每秒吉比特吞吐，是 TLS 数据面的绝对主力；
• 分发困境：n 方全互联需要 n(n-1)/2 把密钥，二次增长使开放网络无法纯靠对称密码运营；
• 过渡方案：KDC/Kerberos 把密钥量降为线性，但引入中心单点；根本解法要等下一章的公钥密码。

钥匙的问题先记下。下一节钻进算法内部，看 Lucifer 到 DES 的 16 轮 Feistel 如何把香农公理铸成电路，AES 的 SPN 结构又强在哪。