2. 密码学原语在TLS中的角色

学习TLS最容易踩的坑，是把“算法”和“协议”混为一谈。AES-GCM、ECDHE、SHA-256、HMAC都是密码学原语，它们各自只解决一个具体问题；而TLS是一套把多种原语按固定顺序组合起来的协议框架。理解TLS，本质上就是理解“哪个原语在哪个阶段、承担什么职责、彼此如何衔接”。

本节先建立一张职责地图，再逐一说明每种原语在TLS 1.3中的具体用途与组合方式。

对称加密：AEAD 是记录层的核心

TLS 1.3 只允许 AEAD（带关联数据的认证加密）算法保护应用数据，具体是 AES-GCM 和 ChaCha20-Poly1305 两类。AEAD 的关键特征是：一次加密操作同时输出密文和认证标签，解密时若标签校验失败则直接拒绝，不会返回任何明文。这消除了“先解密再校验 MAC”的顺序风险。

AES-GCM 在硬件支持 AES-NI 的平台上性能极佳，适合服务器和桌面环境；ChaCha20-Poly1305 在缺少 AES 硬件加速的移动设备上表现更好，且实现更简单、抗侧信道能力更强。两者在 TLS 1.3 中都是强制实现套件，客户端和服务端通过 ClientHello 的 signature_algorithms 与 cipher_suites 协商选择。

需要特别区分：AES-GCM 中的 GHASH 是认证部分，不是独立的 MAC 算法；ChaCha20-Poly1305 中的 Poly1305 同理。它们内嵌在 AEAD 构造里，不应与 HMAC 混为一谈。

非对称加密：密钥交换与身份签名是两件事

非对称原语在 TLS 中承担两个完全不同的职责，这是最容易混淆的地方。

ECDHE（临时椭圆曲线 Diffie-Hellman）用于密钥交换。客户端和服务端各自生成临时密钥对，交换公钥后独立计算出相同的共享秘密。由于私钥是临时的、握手后即丢弃，即使服务器长期私钥泄露，攻击者也无法解密历史会话，这就是前向保密。TLS 1.3 强制使用 ECDHE 或 DHE，彻底移除了 RSA 密钥传输。

RSA 和 ECDSA用于数字签名，验证服务器证书的真实性。服务器用私钥对握手消息的哈希值签名，客户端用证书公钥验证。RSA 签名依赖大整数分解难题，ECDSA 依赖椭圆曲线离散对数难题。它们只证明“这个公钥属于这个域名”，不参与会话密钥的生成。

一个常见误解是“RSA 加密了数据”。在 TLS 1.3 中，RSA 只做签名，不做加密；应用数据全部由 AEAD 对称加密保护。

哈希：SHA-256 与 SHA-384 的绑定作用

哈希函数在 TLS 中不直接加密数据，而是提供“绑定”和“摘要”能力。SHA-256 和 SHA-384 用于三个场景：一是证书签名中的消息摘要；二是握手过程中计算 Transcript Hash，把 ClientHello、ServerHello、证书、密钥交换等所有握手消息按顺序拼接后哈希，确保双方看到的握手内容完全一致；三是作为 HKDF 的底层哈希，派生各类密钥。

Transcript Hash 是 TLS 1.3 安全性的关键设计。Finished 消息的校验值就是基于 Transcript Hash 计算的，任何握手消息被篡改都会导致哈希不匹配，握手立即失败。

MAC 与 HKDF：密钥派生的引擎

HMAC 在 TLS 1.3 中不直接保护应用数据，而是作为 HKDF（HMAC-based Key Derivation Function）的底层 PRF。HKDF 分两步：Extract 阶段用 HMAC 把 ECDHE 共享秘密和盐值压缩成固定长度的伪随机密钥；Expand 阶段再用 HMAC 扩展出多个密钥，分别用于客户端写、服务端写、客户端读、服务端读以及各自的 IV。

这种“一个共享秘密派生多把密钥”的设计，确保了不同方向、不同用途的密钥相互独立。即使某一方向的密钥泄露，也不会影响其他方向。

组合方式：一张表看清职责边界