Termius 后量子加密是什么 | mlkem768x25519-sha256 KEX 实际意义
为什么现在要关心后量子加密
从 RSA 到 ECDH 再到 Ed25519，SSH 的密钥交换算法一直在升级。每次升级都是为了应对未来可能出现的威胁。
量子计算是下一个威胁：
- Shor 算法能在多项式时间内破解 RSA 和 ECDSA
- 理论上量子计算机在 10 年内可能具备足够规模
- 今天被截获的加密流量可以等量子计算机成熟后再解密（「现在收集，以后解密」攻击）
- 所以现在就要把加密升级到量子计算机也解不开的算法
后量子加密是什么
后量子加密（Post-Quantum Cryptography，PQC）是抗量子计算攻击的密码学算法。NIST 花了多年从全球征集的方案中选出了几种标准算法，ML-KEM 就是其中之一。
ML-KEM（Module-Lattice-Based Key Encapsulation Mechanism）基于格密码（Lattice-based cryptography）——数学上，大格上的最短向量问题（SVP）连量子计算机也解不动。
Termius 用了什么
9.25.0 版本起，Termius 新增支持密钥交换算法 mlkem768x25519-sha256。
这是一个混合方案：
- X25519：经典椭圆曲线密钥交换（今天大家都在用）
- ML-KEM-768：后量子格密码密钥交换
两个算法同时跑，得到的密钥混合在一起。这样：
- X25519 提供今天的安全（经典计算机解不动）
- ML-KEM-768 提供未来的安全（量子计算机解不动）
- 混合 = 最强安全保证
NIST 标准对应
- ML-KEM-768 对应 NIST FIPS 203 的安全级别 3（约等于 AES-192）
- mlkem768x25519-sha256 是 IETF draft 里定义的混合 KEX 方案
实际效果
对普通用户
- 自动生效，不需要配置
- 连接支持 PQC 的服务器时自动使用新算法
- 不支持的服务器自动降级回普通 X25519
- 速度上多了一点计算开销（ML-KEM-768 的计算量比 X25519 大），但对终端 SSH 来说完全无感
对服务器端
- 服务器的 OpenSSH 版本需要支持 PQC KEX
- OpenSSH 9.0+ 开始支持 NTRU 系列，但 ML-KEM-768 的支持需要更晚版本
- 目前实际部署 PQC 的服务器还不多，但在快速跟进
关键意义
现在用混合 KEX 建立的 SSH 会话，即使 10 年后量子计算机成熟了也解不开。这直接防御了「现在收集，以后解密」的长期情报攻击。
和其他 SSH 客户端的对比
| 客户端 | PQC KEX 支持 | 版本 |
|---|---|---|
| Termius | ✅ mlkem768x25519-sha256 | 9.25.0+ |
| OpenSSH | ✅ NTRU / ML-KEM（逐步支持） | 9.0+ |
| PuTTY | ❌ | 最新版本还没有 |
| SecureCRT | ❌ | 最新版本还没有 |
| Xshell | ❌ | 最新版本还没有 |
| Windows Terminal | ❌ | 依赖 OpenSSH，但 Windows 自带 OpenSSH 版本较老 |
Termius 在这件事上行动得很快，说明安全投入是产品优先级。
这对你意味着什么
个人用户
- 享受更强的未来安全，不用做任何事
- 换新版本 Termius 就自动有了
- 服务器端暂时不支持也没关系（自动降级）
企业运维
- 开始关注服务器 OpenSSH 版本，规划 PQC 升级
- 审计内部 SSH 客户端是否支持 PQC
- 把 PQC 支持纳入硬件和系统的采购清单
合规场景
某些合规框架（比如 PCI DSS、FedRAMP）要求升级到后量子加密算法。Termius 的 PQC 支持能帮助满足这些要求。
局限性
- 只有密钥交换（KEX）层升级了，数据加密层（对称加密）还是 AES-256-GCM——不过 AES 本身抗量子，不需要换
- 服务器端需要配合升级，客户端单方面升级没用（会自动降级）
- ML-KEM-768 的性能比 X25519 略差（握手时多几毫秒），但对 SSH 这种长连接影响可忽略
未来方向
- Termius 后续可能增加更多 PQC KEX 方案
- 也可能在 FIDO2 硬件密钥里集成 PQC 支持
- 标准化和生态的成熟需要时间（服务器端全面支持至少还需要 2~3 年）
一句话：Termius 已经把防量子计算攻击的锁装上了，你的服务器迟早也要换把新锁，换了之后两边匹配上就自动生效。