网络笔记：加密、哈希与密钥交换

讲 IPSec、TLS、PKI 之前，得先把密码学这三类东西分清楚。它们经常被混着说，但解决的问题完全不同——搞混了，后面看配置项就会一头雾水。

一句话分工

最容易搞错的一点：哈希不是加密。加密是可逆的（有密钥能还原），哈希是不可逆的（只能比对，不能还原）。用哈希「加密」密码，本质上只是存了一个指纹。

对称加密

同一个密钥既加密又解密，速度极快（硬件 AES 能跑到几十 Gbps），所以真正保护数据的是它。

常见算法

分组模式：比算法本身更容易出事

分组密码只能加密固定长度的块（AES 是 128 位 = 16 字节），长数据要靠「模式」串起来。这里踩坑最多。

ECB（电子密码本）  ★ 绝对不要用
  ┌────────┬────────┐        ┌────────┬────────┐
  │ 明文块1 │ 明文块2 │  ──►   │ 密文块1 │ 密文块2 │
  └────────┴────────┘        └────────┴────────┘
  同样的明文块 → 同样的密文块
  → 图片加密后还能看出轮廓（著名的"ECB 企鹅图"）

CBC（密码块链接）  ★ 常见，需要 IV
  每个明文块先和前一个密文块异或，再加密
  → 同样的明文块产生不同密文
  → 缺点：只能串行加密，慢；且需要随机的 IV（初始化向量）

CTR / GCM  ★ 现代首选
  把分组密码当成流密码用，可以并行
  GCM 还额外提供「认证」（防篡改），一个算法同时搞定保密 + 完整性
  → IPSec 里 AES-GCM 就是这种组合

IPSec 配置里的 esp encryption-algorithm aes-256 只是选算法，实际跑的时候还会带模式。看到 aes-256-gcm 这种写法就是「算法 + GCM 模式」。

非对称加密

公钥可以随便公开，私钥只有自己知道。用公钥加密的东西，只有私钥能解开——这就解决了「怎么把对称密钥安全地给对方」。

为什么非对称加密不直接用来传数据？太慢。RSA-2048 的吞吐大概只有 AES 的千分之一量级。所以它的定位是「把对称密钥安全地送过去，然后交给对称加密干活」。

数字签名：反着用非对称加密

加密是「公钥加密、私钥解密」，签名刚好反过来：

签名（发送方）：
  原文 ──哈希──► 摘要 ──用【私钥】加密──► 签名值
  发送：原文 + 签名值

验签（接收方）：
  收到的原文 ──哈希──► 摘要A
  收到的签名值 ──用【发送方公钥】解密──► 摘要B
  摘要A == 摘要B ？ → 通过

  ★ 只有持有私钥的人能生成合法签名 → 证明身份（不可否认）
  ★ 原文改一个字节，摘要就完全不同 → 证明完整性

为什么是"先哈希再签名"而不是直接签原文？
  → 原文可能很大，RSA 一次只能处理固定长度
  → 哈希把任意长度压成定长，签名才可行

哈希与 HMAC

HMAC（Hash-based Message Authentication Code）是在哈希里混入一个共享密钥：HMAC = Hash(密钥 + 原文)。

区别在于：普通哈希谁都能算，攻击者改完原文重算一遍摘要就骗过去了；HMAC 没有密钥算不出来，所以能同时验证完整性和来源。IPSec 的 authentication-algorithm sha2-256 配的就是这一类。

DH 密钥交换：密钥本身从不上网

这是整套密码学里最漂亮的一招。双方要在完全不安全的信道上协商出一个只有他俩知道的密钥。

公开参数（谁都能看到）：大素数 p、生成元 g

        Alice                          Bob
  选私钥 a（保密）               选私钥 b（保密）
  计算 A = g^a mod p            计算 B = g^b mod p
        │                              │
        └──────── 交换 A 和 B ─────────┘
        │                              │
  收到 B，算 B^a mod p          收到 A，算 A^b mod p
        │                              │
        └──── 结果都是 g^(ab) mod p ────┘
                  ↓
             这就是共享密钥

★ 中间人截获了 p, g, A, B
★ 但想算出 g^ab 需要先解出 a 或 b —— 这就是【离散对数难题】
★ 密钥从未出现在网络上

但是 DH 有个致命缺陷

它不认证身份。中间人可以对 Alice 假装是 Bob、对 Bob 假装是 Alice，各建一条 DH，然后转发所有流量（中间人攻击）。

解决办法有两个，IPSec 里都用得上：

• 预共享密钥（PSK）：两边配同一个密码，用它来认证 DH 交换；
• 数字证书 / 数字签名：用 RSA 或 SM2 签名来证明身份，也就是 PKI 那一套。

另外，纯 DH 还有个前向安全的问题（私钥泄露则历史流量可解），所以现在用 DHE / ECDHE——每次会话重新生成临时密钥对，用完就扔。

实际协议怎么组合

第 1 步  非对称（DH / RSA）  协商出会话密钥 + 认证对端身份
第 2 步  对称（AES / SM4）   用会话密钥加密真正的数据
第 3 步  哈希（SHA-256 / HMAC）校验数据完整性，防篡改

IPSec 里这套协商过程叫 IKE（Internet Key Exchange）
  IKE 跑在 UDP 500 上（NAT 穿越时用 4500）
  IKE Phase 1：建 IKE SA，双方认证身份、协商出 IKE 的密钥
  IKE Phase 2：用 IKE SA 保护，协商出真正加密数据的 IPSec SA
  → 所以 IPSec 是"两阶段协商"，配置里也能看到两套 proposal

几个实际会踩的点

• 「哈希 = 加密」是错的，写文档时别混用，否则后面讲 PKI 会绕不出来；
• 别用 ECB，哪怕算法选了 AES；
• MD5 不要用在安全场景（IPSec 里 authentication-algorithm md5 属于历史遗留配置，新项目不要这么写）；
• DH 的 group 号越大越安全也越慢：group 2（1024 位）已不推荐，现在一般用 group 14（2048 位）或以上，或直接用 ECDH；
• 两端的算法集必须匹配：IKE 协商时双方各提交一组 proposal，取交集。两端配置不一致，最常见的表现就是「隧道起不来，日志里说 no proposal chosen」。

一句话总结：对称加密保内容、非对称加密保密钥和身份、哈希保完整性。真实协议是三者的流水线：先用非对称协商出对称密钥并认证身份，再用对称加密数据，最后用哈希校验。DH 是协商环节的核心，但它本身不认证身份——那件事交给 PKI。