算法协商机制基础
说到密码算法协商，我脑子里第一个蹦出来的场景就是：两台设备第一次握手，互相打量对方——"嘿，你支持什么算法？" "我支持这些，你呢？" 然后两边挑一个双方都认的算法，开始加密通信。
这个过程，说白了就是算法协商。它不是什么高深理论，而是网络通信中最务实的环节。没有它，两边各说各话，根本聊不到一块去。
什么是密码算法协商
密码算法协商，就是通信双方在建立安全通道之前，先交换各自支持的算法列表，然后从中选出一套双方都认可的组合。这套组合通常包括：
- 密钥交换算法 —— 怎么安全地交换密钥材料
- 认证算法 —— 怎么验证对方身份
- 对称加密算法 —— 用什么算法加密数据
- 消息认证码（MAC）算法 —— 怎么保证数据完整性
- 哈希算法 —— 用于数字签名和密钥派生
我遇到过不少刚入行的同事，以为协商就是"选一个最强的算法"。其实不是。协商的核心是兼容性——在双方能力范围内，选一个安全级别最高的组合。
核心要点：算法协商不是"谁强听谁的"，而是"双方都能接受的最优解"。这在PQC过渡期尤其重要——老设备可能只支持传统算法，新设备想用PQC，怎么兼容？协商机制就是答案。
TLS 1.3中的密码套件协商
TLS 1.3的协商机制，我个人觉得是这几个协议里最优雅的。它把密码套件（Cipher Suite）的数量从TLS 1.2的几十种砍到了5种。为什么？因为太多选择反而容易出配置错误。
在TLS 1.3中，协商过程大致是这样的：
- ClientHello：客户端发送支持的密码套件列表，以及密钥交换参数（比如ECDHE的公钥）
- ServerHello：服务端从列表里选一个套件，返回自己的密钥交换参数
- 密钥派生：双方用协商好的算法，结合交换的参数，派生出会话密钥
- Finished：互相验证握手消息的完整性
这里有个关键变化：TLS 1.3的密码套件只指定认证算法 + 对称加密算法 + 哈希算法，密钥交换算法是单独协商的。举个例子：
TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256你看，套件里没有"ECDHE"或者"RSA"这样的密钥交换标识。密钥交换算法是在扩展字段里协商的。这样做的好处是灵活——以后想加新的密钥交换算法，不用改密码套件定义。
实战经验：我在帮客户迁移到PQC时，TLS 1.3的扩展机制帮了大忙。我们只需要在ClientHello的扩展里加上PQC密钥交换算法的标识，服务端如果支持，就能直接协商。不需要改密码套件，也不需要升级整个TLS协议版本。
SSH中的密钥交换算法协商
SSH的协商方式和TLS不太一样。它更"直白"——双方先交换协议版本号，然后直接交换算法列表，逐项协商。
SSH的协商过程分为几个阶段：
- TCP连接建立：客户端连接服务端的22端口
- 协议版本交换：双方确认SSH协议版本（通常是2.0）
- 算法列表交换：客户端和服务端各自发送支持的算法列表，包括密钥交换算法、主机密钥算法、对称加密算法、MAC算法、压缩算法
- 密钥交换：用协商好的算法执行实际的密钥交换
SSH的算法列表是明文传输的。嗯，这里要注意——虽然列表是明文，但密钥交换过程本身是加密的。列表泄露不会直接导致安全问题，但攻击者可以知道双方支持哪些算法，从而针对弱算法发起降级攻击。
我曾经在一个项目中遇到过SSH协商失败的问题。原因是服务端配置了PQC密钥交换算法，但客户端不支持，而服务端又把传统算法全禁用了。结果两边找不到共同算法，连接直接断开。这个教训让我养成了一个习惯：在启用新算法时，一定要保留至少一个传统算法作为回退。
避坑指南：我曾经见过有人把SSH的KexAlgorithms配置成只支持一个实验性的PQC算法，结果所有客户端都连不上。SSH的协商是"必须找到共同算法才能继续"，不像TLS可以优雅降级。所以配置SSH算法时，一定要留后路。
IPsec中的算法协商
IPsec的协商机制比TLS和SSH都复杂。它分两个阶段：
- 阶段1（IKE_SA_INIT）：协商IKE本身的安全参数，建立IKE SA
- 阶段2（IKE_AUTH + CREATE_CHILD_SA）：在IKE SA的保护下，协商IPsec SA的具体参数
IPsec的算法协商是通过安全关联（SA）来管理的。每个SA包含一组算法参数，比如：
| 参数 | 说明 | 常见选项 |
|---|---|---|
| 加密算法 | 保护数据机密性 | AES-GCM, AES-CBC, ChaCha20 |
| 完整性算法 | 保护数据完整性 | HMAC-SHA256, HMAC-SHA384 |
| 密钥交换算法 | 安全交换密钥材料 | Diffie-Hellman, ECDH, PQC KEM |
| 伪随机函数 | 用于密钥派生 | PRF-HMAC-SHA256 |
| DH群组 | 指定Diffie-Hellman的参数 | Group 14, Group 19, Group 20 |
IPsec协商的一个特点是提议-响应机制。发起方可以发送多个提议（Proposal），每个提议包含一组算法组合。响应方从这些提议中选一个它最认可的。如果都不认可，协商失败。
我在做IPsec VPN迁移时，发现一个常见问题：很多设备默认只支持有限的DH群组。比如老设备只支持Group 2（1024位模数），这在今天已经不安全了。但如果你直接禁用Group 2，老设备就连不上了。我的做法是：在配置中保留Group 14（2048位）作为最低要求，同时启用更高强度的群组。
关键对比：
- TLS 1.3：协商一次，密码套件精简，扩展机制灵活
- SSH：逐项协商，算法列表明文交换，需要小心降级攻击
- IPsec：两阶段协商，提议-响应机制，参数多且复杂
你想想看，这三种协议的协商机制，本质上都是在解决同一个问题：两个不知道对方能力的实体，如何安全地达成一致。只是各自的实现方式不同，复杂度也不同。
在PQC过渡期，理解这些协商机制的细节特别重要。因为你要在现有协议框架里，把PQC算法"塞"进去。有些协议好塞（比如TLS 1.3的扩展），有些协议难塞（比如IPsec的DH群组列表）。
下面这张图，我把三种协议的协商流程画在一起，方便你对比：
这张图把三种协议的协商流程放在一起对比。你可以看到，TLS 1.3最简洁，SSH最直白，IPsec最复杂。但不管哪种协议，核心逻辑都一样：先交换能力，再达成一致。
在PQC过渡期，我建议你重点关注两个问题：
- 降级攻击：攻击者可能干扰协商过程，迫使双方使用弱算法。TLS 1.3通过"降级保护"机制解决了这个问题，但SSH和IPsec需要你自己配置防护
- 兼容性回退：新算法不一定被所有设备支持。一定要保留至少一个传统算法作为回退，否则会出现"协商失败"的尴尬局面
嗯，算法协商机制就讲到这里。理解了这些基础，后面我们才能深入讨论如何在PQC过渡期设计安全的协商策略。