加密基础：对称 / 非对称 / 哈希与组合模式

想象这样一天：你注册了一个新网站，密码用 SHA-256 存进 DB——第二天被拖库，攻击者用 GPU 集群三分钟破译；你写了一个内网 API，用 SHA256(密钥 + 请求体) 做签名——两周后被伪造调用，钱财转空；你上线 TLS，为了兼容老客户端保留了 RSA 密钥交换——三个月后服务器私钥泄露，去年一整年的历史流量被回放解密。这三种事故的根源都不是"忘了加密"，而是把三大原语（对称/非对称/哈希）的组合方式搞错了。本篇是站点加密原理的单一事实源：一次讲通对称、非对称、哈希三块砖，再把 AEAD、HMAC、数字签名、密钥交换、KDF 这些组合方式搭起来，最后落到 TLS / JWT / mTLS 三个真实协议。

大白话入门

先用最土的话讲清楚这门学问在干什么、发展到今天为止解决了哪些问题。术语一律先翻译成中文，读到后面就不会被吓退。

密码学到底在解决什么？

抛开所有术语，密码学只有四个目标：

关键洞察：一个真实协议（TLS、JWT、mTLS）通常要同时满足前三个目标（TLS 还额外要"前向安全"）。所以你会看到 TLS 里同时用了对称、非对称、哈希、签名、密钥交换、KDF——不是炫技，是因为这四个目标要用不同的工具。

一张图看懂发展史（1976 → 2024）

演进主线三句话：

1. 对称 → 非对称（1970s）：解决"陌生人怎么协商密钥"这个死结。
2. 手拼加密+MAC → AEAD（2000s→2018）：一步做完，杜绝 Padding Oracle 类实现坑。
3. RSA → 椭圆曲线 → 抗量子（1977→2012→2024）：性能提升 + 应对未来量子威胁。

术语速查表（先扫一遍，读正文时随时翻回来）

这一节读者可以直接跳过，遇到不认识的词再回来查。

分类 1：基础对象

IV vs Nonce vs Salt 的差别：都是"随机数"，但要求不同：

• IV：唯一即可，可以公开（CBC）
• Nonce：唯一即可，可以公开，但同密钥下绝不能重复（GCM/CTR）
• Salt：唯一即可，可以公开，用于密码存储

分类 2：算法类别

分类 3：具体算法

分类 4：工作模式与结构

分类 5：协议与工程

一个新手最常混淆的对比

在读正文前，先把最容易搞混的三对说清楚：

混淆点 1：加密 vs 编码 vs 哈希

• 编码（Base64、URL encode）：不是加密，任何人可逆。目的是"让二进制能在文本协议里传输"。
• 加密（AES）：可逆（有密钥才能解开）。目的是保密。
• 哈希（SHA-256）：不可逆。目的是产生指纹，不是保密。

混淆点 2：签名 vs 加密

• 都用非对称密钥对，但方向相反（前面 SVG 图讲过）。
• 加密：接收方公钥 → 私钥（保密）
• 签名：签名方私钥 → 公钥（认证）
• 签名不加密内容——原消息还是明文传，签名只是附加的一段可验证字节。

混淆点 3：HMAC vs 数字签名

• HMAC：双方共享密钥（对称的思路，只是用哈希实现）
• 数字签名：私钥签、公钥验（非对称）
• 区别的核心是"信任模型"：HMAC 双方互信，签名单向。

场景问题

一个能秒懂的类比：三种"锁"

假设你要给朋友寄东西，市面上有三种"锁"，选错了就出事：

工程上永远是这三者混着用——用挂锁把钥匙寄过去（非对称），用钥匙锁大件（对称），加封条防拆（哈希）。TLS / SSH / mTLS / JWT 都是这个套路的变种。

面试高频翻车题

实现方案

下面开始正式讲。先看整体地图，再逐块拆解——这样后面每讲一个原语你都知道它落在哪里：

读图窍门：紫色是砖（原语）、蓝色是灰浆（组合方式）、绿色是最终房子（真实协议）。任何"这个协议为什么这样设计"都能顺着箭头往回追。

一、对称加密：一把钥匙开关

故事场景

你和朋友想私下聊天，事先在见面时对好了一句暗号（对称密钥）。之后就用暗号把信息编码后发出去——谁截获都读不懂，除非他也知道暗号。

问题只有一个：第一次怎么把暗号安全地告诉朋友？（——这就是后面非对称加密要解决的问题。）

直觉画面

关键点：加密和解密用的是同一把钥匙——所以叫"对称"。

术语与家族

• 分组密码 vs 流密码：AES 属于分组密码——一次处理固定长度的一块（AES 是 16 字节 = 128 bit）；ChaCha20 属于流密码——像一条无穷长的伪随机比特流，逐字节 XOR 你的明文。
• AES 家族：AES-128 / AES-192 / AES-256（数字是密钥长度），底层结构叫 SPN（Substitution-Permutation Network），面试不用深挖细节，知道"AES-256 是当前工业界默认最强对称算法"就够。
• 工作模式：AES 一次只能加 16 字节。真实消息几 KB 几 MB，就需要"工作模式"告诉 AES 怎么把一块一块拼起来。这里就有大坑：

深入：ECB 为什么禁用（一张图讲透）

看出问题了吗？明文块 1 和 2 相同 → 密文块也相同。这在加密位图时最直观：一张企鹅图片加密完还是能看出企鹅的轮廓（对应像素颜色相同的地方，密文也相同）。

CBC 怎么修：让每一块都异或前一块的密文，第一块异或一个随机 IV：

即使明文块 1 和 2 相同，因为前一块密文不同 → 异或结果不同 → 输入 AES 的东西不同 → 密文不同。图案泄露解决。

现代默认：AEAD（一步到位）

AEAD = Authenticated Encryption with Associated Data（带关联数据的认证加密）。一步做完三件事：机密性 + 完整性 + 认证。主流两个：

• AES-256-GCM：有 CPU 硬件加速（AES-NI）时首选，云端和现代 x86/ARM 服务器都有。
• ChaCha20-Poly1305：没硬件加速的场景（老手机、嵌入式）首选，纯软实现比 AES 快。

类比：AEAD = 快递箱 + 一次性防伪封条

AAD（Associated Data）：参与认证但不加密的字段。典型用途：HTTP 头、连接 ID——你不想加密它（否则中间节点看不到路由信息），但改动它 tag 会失效。

GCM 的 tag 挂在密文哪里（Go 伪码，非可运行程序）：

// 加密：Seal(dst, nonce, plaintext, additionalData) → dst = ciphertext || tag
block, _ := aes.NewCipher(key32)          // 32 字节 = AES-256
aead, _ := cipher.NewGCM(block)           // 默认 12-byte nonce, 16-byte tag
nonce := make([]byte, aead.NonceSize())
rand.Read(nonce)                          // MUST 每次唯一：随机 or 单调计数器
ct := aead.Seal(nil, nonce, plaintext, aad) // ct 末尾自带 16 字节 tag
// 传输：nonce || ct（含 tag）

// 解密：Open() 内部先验 tag，失败直接返回 error，不吐半字节明文
pt, err := aead.Open(nil, nonce, ct, aad)

要点：tag 拼在密文尾部、Open 先验后拆——tag 不对直接失败，绝不返回"半解密"的中间结果。这是 AEAD 相对"CBC + HMAC 手拼"的关键防御边界（后面 HMAC 章节会讲为什么）。

二、非对称加密：公开挂锁 + 私钥

故事场景

回到刚才的坑：Alice 和 Bob 想用对称加密聊天，但他们没见过面——怎么把对称密钥安全地告诉对方？直接寄过去中间人一截获就完蛋。

Diffie 和 Hellman 1976 年提出了神奇的方案：Bob 造一把"任何人都能锁上、只有 Bob 能打开"的挂锁，把挂锁的图纸公开挂在网上。Alice 想聊天时：

1. 下载 Bob 的挂锁图纸（公钥）
2. 用挂锁把自己生成的对称密钥锁进一个箱子（加密）
3. 把箱子寄给 Bob

中间人截获箱子——没用，因为只有 Bob 的钥匙（私钥）能开。

直觉画面：RSA 加密

最大的坑：加密和签名的"钥匙方向相反"

RSA 有两个用途，钥匙方向正好相反——这是面试最爱考的一点。

记忆口诀：

• 加密："公锁私开" —— 谁想给我发密文，就用我的公钥（公开的锁）加密；我用自己的私钥（唯一的钥匙）打开。
• 签名："私签公验" —— 我要证明这消息是我发的，就用我的私钥签名；任何人拿我的公钥都能验证。

想想这个对称性为什么合理：

• 加密目标是 "只有一人能读" → 用只有一人有的东西解密 → 用私钥解
• 签名目标是 "只有一人能写" → 用只有一人有的东西加密 → 用私钥签

术语与家族

为什么非对称"只用于握手"：性能差距太大。AES-GCM 单核吞吐 GB/s，RSA-2048 签名单核每秒几千次——差 5 个数量级。全程非对称直接不可用。所以工程上永远是：非对称谈钥匙 + 对称跑数据。

三、哈希：单向指纹

故事场景

你从网上下载了一个 5GB 的镜像文件。怎么确认下载过程中没有被中间人替换？镜像的官方页面上贴了一段 64 位十六进制字符串——那就是哈希值。你本地也算一遍：一样，说明下载完整；不一样，说明有变化（无论是无意损坏还是恶意替换）。

哈希函数满足两个特性：

• 单向：给你哈希值 h，反推原始数据 m 计算不可行（不可能用 SHA-256 值倒推出源镜像）。
• 雪崩：输入变一个 bit，输出完全变样（一半以上的 bit 翻转）。

直觉画面

无论输入 11 字节还是 5GB，输出都是固定 32 字节。输入哪怕改一个字符，输出完全不一样。

术语与家族

• SHA-2（SHA-256/384/512）：2001 年至今主力，未被攻破。
• SHA-3（Keccak）：2015 年标准化，用了完全不同的"海绵结构"，抗性更强，但性能通常不如 SHA-2。
• BLAKE2 / BLAKE3：速度极快，工程界流行，非官方标准。
• MD5 / SHA-1：已弃用。MD5 (2004 年被攻破，秒级构造碰撞)、SHA-1 (2017 年 Google SHAttered 攻破)。仅限非安全场景（如 Git 对象寻址、CDN 缓存 key）。

三性质：能防什么、不能防什么

抗碰撞是最强要求，MD5/SHA-1 就栽在这里。

红线：哈希 ≠ MAC（下一节详细讲）

一个新手最容易犯的错："用 SHA-256 加密"。哈希不是加密——它是单向的、无法还原。哈希只能做完整性校验（你我都算一遍看结果一样不一样），不能防主动攻击——攻击者拿到消息可以自己重算一份哈希，让你以为没被改。要防主动攻击，得让哈希"知道秘密"——那就是 HMAC 或数字签名。

四、HMAC：给哈希加一把密钥

故事场景

内网服务 A 调用服务 B 的计费 API，怎么让 B 确认"这个请求真的是 A 发的、路上没被改过"？

方案一（错）：让请求带一个 signature = SHA256(secret + body)——A 和 B 共享 secret。B 收到后自己算一遍对得上就通过。这有致命漏洞：SHA-2 存在长度扩展攻击——攻击者拿到 SHA256(secret + body) 输出，即使不知道 secret，也能算出 SHA256(secret + body + padding + evil_data)，让 B 以为是合法扩展。

方案二（对）：用 HMAC（Hash-based Message Authentication Code），双层哈希封住这个漏洞。

直觉画面：HMAC 的双层结构

公式：HMAC(K, m) = SHA256( (K ⊕ opad) || SHA256( (K ⊕ ipad) || m ) )

• ipad = 0x36 重复到密钥长度（"inner padding"）
• opad = 0x5C 重复到密钥长度（"outer padding"）
• ⊕ 是异或

为什么这个双层结构能抵御长度扩展：攻击者拿到的是外层哈希的输出，看不到内层哈希的状态——就无法从"外层输出"扩展一个消息使 HMAC 依然合法。SHA-3 因用海绵结构天然免疫，但工程界仍统一走 HMAC 保持算法族无关。

术语与选型

Go API 示例：

import "crypto/hmac"
import "crypto/sha256"

mac := hmac.New(sha256.New, sharedSecret)
mac.Write([]byte(message))
sig := mac.Sum(nil) // 32 字节的认证码

// 验证时（重要！用 hmac.Equal，防时序侧信道）
ok := hmac.Equal(receivedSig, sig)

五、AEAD 内部：为什么"先加密再 MAC"

上面讲了对称、HMAC，现在回头看 AEAD 为什么"一步到位"更安全。要 既加密又认证，历史上有三种拼接顺序，只有一种真正安全：

为什么 EtM 最优：解密方拿到消息后先验 MAC 再解密。MAC 不对直接丢弃——攻击者无法通过"送畸形密文观察解密行为"来构造侧信道。这是历史上 Padding Oracle 攻击（BEAST/Lucky13/POODLE）的成因：它们都发生在"手拼 MtE"上，因为解密方要先解密到 padding 再验证。

AEAD 就是把 EtM 一体化封装：AES-GCM 内部结构 = CTR 模式加密 + GMAC 认证 + 一起产 tag。你只调 Seal/Open，不可能拼错。

六、数字签名：只有一个人能写

故事场景

Alice 要发一个软件更新包给全世界的用户。用户怎么确认"这真的是 Alice 发的，不是黑客伪造"？

用 HMAC 不行——HMAC 需要双方共享密钥，Alice 不可能给每个用户都发一份共享密钥（发出去就等于所有用户都能伪造 Alice 的签名）。

用数字签名：

1. Alice 私钥签一次
2. 公钥挂在官网人人可下载
3. 任何用户拿公钥验签

关键差别：签名做到了 HMAC 做不到的一件事——不可抵赖。因为签名需要私钥，只有 Alice 有；HMAC 双方共享密钥，收方也能签，所以事后 Alice 可以说"这不是我签的"。

直觉画面

术语与选型

HMAC vs 数字签名：什么时候用哪个

七、密钥交换：ECDHE 与前向安全

故事场景

回到最开头 Alice 和 Bob 的问题：他们没见过面，怎么协商出一个共享的对称密钥？

RSA 方式：Bob 挂公钥，Alice 用它加密对称密钥发过去。有个隐患：如果 Bob 的私钥明年被偷了，攻击者去年录下的整箱流量今年全部可解（因为对称密钥当时就是用 Bob 那把私钥的公钥加密的）。

Diffie-Hellman 密钥交换的神奇之处：让 Alice 和 Bob 通过公开信道算出一个共享秘密，中间人虽然全程能看到通信，但算不出这个秘密。

直觉画面：ECDHE 一次会话

为什么中间人算不出：给你 a·G，反推 a 需要解"椭圆曲线离散对数难题"——目前没有已知的多项式时间算法（除了量子计算机，见文末 PQC 章节）。

术语解释：ECDHE 里的每个字母

• DH = Diffie-Hellman，1976 年的原始算法
• EC = Elliptic Curve（椭圆曲线），把整数域换成椭圆曲线群，密钥更短更快
• E = Ephemeral（临时）——每次会话生成一次性密钥对，用完即弃

这个 E 就是前向安全的关键：

这就是 TLS 1.3 直接砍掉 RSA 密钥交换、只保留 ECDHE 的原因。

八、KDF：从秘密派生子密钥

故事场景

Alice 和 Bob 通过 ECDHE 算出了一段共享秘密 S（比如 32 字节）。他们需要：一把加密密钥、一把 MAC 密钥、一个初始 IV……能不能直接把 S 切成几段用？

不能。原因：

1. S 是椭圆曲线上一个点的 x 坐标，分布不均匀（不是均匀随机的），直接切片会让某些子密钥有偏。
2. 不同用途密钥必须"域分离"——否则会有跨用途的攻击（拿加密密钥当 MAC 密钥用能出事）。

HKDF（HMAC-based Key Derivation Function，RFC 5869）就是干这个的：

直觉画面：HKDF 两步

• Extract：PRK = HMAC(salt, S)——把熵不均匀的输入压成均匀伪随机
• Expand：OKM = HMAC(PRK, info || counter)——按需展开任意长子密钥，info 做域分离

TLS 1.3、Noise 协议、Signal 协议全部用 HKDF。为什么不直接 SHA-256 派生：SHA-256 不是 PRF，直接切片没有形式化安全证明；HKDF 有 IETF 标准证明。

密码存储：为什么要"故意慢"

普通 KDF 追求快，密码存储的 KDF 反着来——故意慢，才能抗离线爆破。

场景：DB 被拖了，攻击者拿到一堆 (用户名, 密码哈希)。他想还原你的密码，只能一个一个试：

• 如果你的密码哈希是 SHA-256(password)：GPU 集群每秒能试数百亿个密码，一个 8 位密码几分钟就爆掉
• 如果是 Argon2id(password, salt, mem=64MB, iter=3)：GPU 每次尝试要花 100ms + 64MB 显存，同样 8 位密码要几十年

必配加盐：每个密码一份随机 salt，与哈希一起存 DB 明文即可。salt 不是"秘密"，它的作用是让并行爆破无法共享预计算表——每个密码都得单独跑一遍完整的 Argon2。

九、TLS 1.3 握手：把上面所有东西串起来

这是最能看清"原语如何组合成协议"的地方。看完这张时序图，前面每一节都会瞬间连起来：

每个原语在做什么（对照前面各节）：

• ECDHE（第七节）：交换密钥份额，双方各自算共享秘密 g^(ab) = 会话根秘密
• HKDF（第八节）：从根秘密派生一堆子密钥
• 服务器证书 + CA 签名链（第六节 + 下面证书章）：证明"这个公钥属于该域名"
• CertificateVerify（第六节）：服务器用证书私钥签整个握手记录 → 防中间人拿别人证书冒充
• Finished（第四节）：用 HKDF 派生的 MAC 密钥做 HMAC → 校验握手过程未被篡改
• Application Data（第一节）：AEAD 加密应用数据

TLS 1.2 → 1.3 的四条大改动：

1. 只留 5 个套件：全部 AEAD + PFS，砍掉 RSA 交换、CBC、RC4、MD5、SHA-1、导出级弱套件。
2. 1-RTT 握手（1.2 是 2-RTT）：ClientHello 直接带上密钥份额；支持 0-RTT 恢复（但有重放风险，不能用于非幂等）。
3. 握手全加密：ServerHello 之后所有帧（含证书）都在派生密钥下加密。
4. 签名与密钥交换解耦：1.2 密码套件同时选中三者组合爆炸，1.3 拆开分别协商。

十、JWT / mTLS / 证书链

JWT：一张自包含的签名令牌

Base64URL(header) . Base64URL(payload) . Base64URL(signature)
      alg=RS256          {sub:123,...}       RSA/HMAC 签名

payload 不加密——只是签名保完整性。需要保密请套 JWE 或走 HTTPS。

HS256 vs RS256 选型：

mTLS：双向 TLS

普通 TLS：只验证服务器证书（防冒充服务器），客户端身份靠应用层认证（用户名密码 / API Key）。

mTLS：客户端也提交证书 → 服务端也验证——双向证书身份。典型场景：

• 服务网格内部身份（Istio / Linkerd 用 SPIFFE ID）——每个服务发一张短期证书，服务间调用全量 mTLS，是"零信任内网"的技术底座
• B2B API
• 金融专线

证书链：谁给谁背书

客户端验证：从叶子证书往上一层层验签，一直验到"内置的可信根证书"停。任何一层验签失败 = 证书不可信。

证书吊销机制（如果 CA 想中途取消一张证书）：

SSH host key 的 TOFU（Trust-On-First-Use）反例：SSH 没有 CA，客户端"第一次连接时把 host key 记下来"，后续变了就报警。适用于无中心信任锚的场景，代价是"首次连接必须可信信道"。

为什么这么做

• 为什么工程上永远是"非对称谈钥匙 + 对称跑数据"：性能差 5 个数量级，全程非对称不可用；纯对称又无法在不安全信道首次交换密钥。混合方案取两者之长，是唯一工程可行的组合。
• 为什么 AEAD 淘汰"CBC + HMAC 手拼"：AEAD 把 EtM 一体化封装，杜绝"实现顺序错 / 侧信道 / 中间态泄露"三类历史事故（Padding Oracle、BEAST、Lucky13 都发生在"手拼"上）。TLS 1.3 只留 AEAD 是必然。
• 为什么 HMAC 不是"哈希 + 密钥拼接"：MD5/SHA-1/SHA-256 的 Merkle-Damgård 结构存在长度扩展攻击。HMAC 的双层结构让内外哈希独立、抵御扩展，且有形式化证明。
• 为什么现代默认 ECDHE 而非 RSA 密钥交换：ECDHE 提供前向安全——今天服务器被攻破偷走私钥，无法反解历史流量；RSA 密钥交换则历史抓包整箱可解。
• 为什么密码存储要慢哈希 + 加盐：SHA-256 单核每秒数亿次，拖库后 GPU 集群离线爆破仅需分钟级；Argon2id 故意消耗 100ms + 数十 MB 内存，把爆破成本抬到 GPU 都跑不动。加盐让每条哈希不能共享预计算表。
• 为什么 JWT 用 RS256 更适合对外 SSO：私钥只在身份提供方（IdP），所有依赖方（Relying Party）用公钥验签——不需要每加一个业务方就派发密钥，运维大幅简化。
• 为什么 TLS 1.3 只留 5 个密码套件：过去"配置一堆套件、按需协商"给了降级攻击（POODLE / FREAK / Logjam）可乘之机。TLS 1.3 直接把不安全套件从标准里删干净，实现无从"协商到弱套件"。

为什么别的选择不行

• 为什么不干脆全程用非对称加密（省得混合）：性能差 5 个数量级——AES-GCM 单核 GB/s，RSA-2048 单核每秒几千次；1MB 数据 RSA 加密数百 ms，全程非对称 = TLS 卡死。且 RSA 一次最多加密（密钥长度 / 8）字节，本身不适合传大数据。
• 为什么不用"哈希 + 密钥拼接"自制 MAC：对 SHA-1/2 存在长度扩展攻击——攻击者不知道 secret 也能扩展你的消息并算出合法 MAC。历史上出过 Flickr API 签名漏洞（2009）。正解是 HMAC。
• 为什么内部服务用 HS256、不图省事全上 RS256：RS256 验签比 HMAC 慢一个数量级——内网每秒万级 QPS 的鉴权累积可观 CPU；且内部服务共享密钥可控，HMAC 的"共享密钥缺陷"在信任域内是可接受权衡。
• 为什么密码不用 AES 加密存 DB、要用慢哈希：一是"加密"意味着可解密——DB 泄露 = 密码全泄；二是密码本身不需要还原，只需"验证一致"，单向哈希才是对的语义。可逆加密只用于确实需要还原的字段（如银行卡号）。
• 为什么不继续用 MD5 做安全场景：签名/证书/密码存储零容忍已破算法；非对抗性寻址场景（Git 内部指针、CDN 缓存 key）碰撞代价可控，暂未强制升级。
• 为什么不给 JWT 加密（JWE）替代签名：签名的目标是可公开验证，加密的目标是保密——两者正交。签名 + HTTPS 已同时提供完整性与传输保密性；JWE 只在"传输后仍需保密载荷"（如票据经不可信中转）时才用。且 JWE 复杂度高、库实现质量参差。

沉淀结论

三张辨析对照表（面试速答模板）

表 1 · RSA 加密 vs RSA 签名

表 2 · HMAC vs 数字签名

表 3 · 哈希 vs MAC vs 签名 能力矩阵

面试快速反应表（场景 → 原语选择）

面试速答清单

• 三大原语：对称快 / 非对称慢 / 哈希不可逆——工程组合永远是"非对称谈钥匙 + 对称跑数据 + 哈希做指纹"
• RSA 加密与签名钥匙方向相反：加密公钥锁、私钥开；签名私钥签、公钥验
• AEAD（GCM / ChaCha20-Poly1305）= 加密 + 完整性 + 认证一体，tag 拼密文尾，Open() 先验后拆
• Nonce 复用等同密钥泄漏（GCM 场景）
• HMAC ≠ "哈希 + 密钥拼接"：双层结构防长度扩展
• 签名 ≠ HMAC：信任模型差在"可抵赖 / 不可抵赖"、"共享 / 私有"
• ECDHE 的 E 是 Ephemeral：每次会话临时密钥 → 前向安全
• HKDF 两步 Extract / Expand，info 做域分离
• 密码存储 Argon2id + 加盐；SHA-256 单调直存 = 被 GPU 秒破
• JWT 用 HS256（内网单验）或 RS256/ES256（对外多验），永远拒绝 alg: none
• TLS 1.3 只留 5 个套件，全 AEAD + PFS，砍 RSA 交换和 CBC

关于 PQC / 同态 / 零知识证明

抗量子密码（NIST 已标准化的 Kyber KEM、Dilithium 签名）、全同态加密（BFV/CKKS）、零知识证明（zk-SNARK/STARK）是独立且深的方向，本篇作为面试基础不深挖；工程侧 2024 起 TLS 已开始试点 X25519+Kyber 混合密钥交换（Chrome / Cloudflare），面试遇到只需知道"存在混合过渡方案、保守不激进"即可。

记忆口诀

• 三大原语：对称快跑数据 / 非对称慢谈钥匙 / 哈希单向做指纹
• RSA 钥匙方向：加密"公锁私开"，签名"私签公验"，方向反了就废
• AEAD 一步到位：GCM/ChaCha20-Poly1305 = 加密 + MAC 一体，tag 拼密文尾
• Nonce 复用 = 泄漏：GCM 同密钥下 Nonce 重复即等同密钥公开
• 哈希 ≠ MAC ≠ 签名：能防篡改/防伪造/防抵赖，三项能力逐级递增
• ECDHE 的 E：Ephemeral 临时密钥，用完即弃 → 前向安全
• HKDF 两步：Extract 压熵 + Expand 分域
• 密码存储：Argon2id + 加盐；MD5/SHA-256 直存等于裸奔
• JWT 三坑：alg: none / 算法降级 / HS256 对外滥用
• TLS 1.3 收敛：只留 AEAD + PFS，砍掉 RSA 交换与 CBC

内容来源

综合整理自：RFC 5246 (TLS 1.2) / RFC 8446 (TLS 1.3) / RFC 2104 (HMAC) / RFC 5869 (HKDF) / RFC 7519 (JWT) / RFC 8017 (RSA-PSS) / RFC 8032 (EdDSA) / RFC 8439 (ChaCha20-Poly1305)、NIST SP 800-38A/D (AES 模式与 GCM)、NIST SP 800-131A (弃用清单)、PHC (Password Hashing Competition, Argon2)、《Cryptography Engineering》(Ferguson / Schneier / Kohno)、Cloudflare / Google 公开博客关于 PQC 混合过渡的部署报告。加密原语跨专题引用点：TLS 协议层视角见本站 http-tls-rpc，接入网关加密落地见 access-gateway，计费签名工程实践见 business-proxy。请以各 RFC 与 NIST 标准原文为准。

自测：合上资料能说清楚吗？

1. RSA 加密和 RSA 签名分别用哪把钥匙？为什么"钥匙方向相反"？

2. 为什么 AES-GCM 的 Nonce 绝对不能重复？重复了会发生什么？

3. 为什么"哈希 + 密钥拼接"（SHA256(K || m)）不是合法的 MAC？HMAC 怎么修的？

4. 什么是前向安全（PFS）？ECDHE 相对 RSA 密钥交换的核心差异是什么？

5. JWT 用 HS256 还是 RS256？alg: none 和算法降级攻击是怎么回事？

6. 密码存 DB 为什么必须用 Argon2id / bcrypt 这类慢哈希，而不是 SHA-256？

7. AEAD 的 tag 到底藏在哪里？Open() 失败时能拿到部分明文吗？

8. mTLS 和普通 TLS 的差别是什么？为什么服务网格喜欢用它？

9. TLS 1.3 相对 1.2 到底改了哪些密码学决定？

10. 抗量子密码（PQC）是不是需要现在立刻切？工程上怎么过渡？