JEP 527：TLS 1.3 的后量子混合密钥交换

引言​

密码学的安全性从来不是一个静态的承诺，而是一场与计算能力的持续赛跑。今天坚不可摧的加密，可能在某个技术拐点之后变得不堪一击。量子计算就是这样一个拐点。JEP 527 让 Java 的 TLS 实现提前为这场赛跑做好准备——而且它做的方式极为务实：默认开启，不动应用代码。

威胁模型：先截获，后解密​

要理解这个 JEP，得先理解它防的是什么威胁。

今天的 TLS 密钥交换建立在**椭圆曲线 Diffie-Hellman（ECDH）**之上。这套数学基础对当前的经典计算机来说足够安全——即使是最强的超级计算机，也无法在合理时间内破解它。

但量子计算机不一样。一台足够强大的量子计算机，借助 Shor 算法，能够高效地攻破椭圆曲线密码学赖以生存的数学难题。目前这样的机器还不存在，但这并不意味着威胁是遥远的。原因在于一种被称为**「先截获，后解密」（harvest now, decrypt later）**的攻击模式：

• 攻击者今天就把你的加密流量原封不动地记录并存储下来。
• 他们并不急于现在破解——只是耐心等待。
• 一旦足够强大的量子计算机问世，他们就把当年存下的流量拿出来批量解密。

换句话说，今天截获的流量，可以等到未来再解密。如果你的数据需要保密十年、二十年——比如医疗记录、国家机密、长期有效的商业合同——那么这个威胁现在就已经是现实的，尽管量子计算机尚未到来。你必须在威胁真正降临之前，就把这些长期数据保护好。

JEP 527 带来了什么​

JEP 527 在 JDK 的 TLS 1.3 实现中加入了混合密钥交换（hybrid key exchange）：

• 它为 TLS 1.3 增加了新的混合密钥交换 named group。
• 具体来说，它把 ML-KEM（基于 Kyber 的、已被 NIST 标准化的后量子密钥封装机制）与传统的 X25519 或 ECDH 组合在一起。
• 最关键的一点：它在 JDK 的 TLS 实现里默认启用。
• 三个混合组中，X25519MLKEM768 默认启用；SecP256r1MLKEM768 和 SecP384r1MLKEM1024 可以通过 TLS 配置启用。
• 它建立在此前若干 JDK 版本已经引入的 ML-KEM 基础支持之上，属于一个渐进推进的路线图中的一步。

默认启用意味着什么？意味着一旦你升级到 Java 27，只要通信对端也支持，你的 TLS 连接就会自动协商启用后量子防护——你不需要写任何代码，甚至不需要知道它的存在。

为什么是混合，而不是纯后量子​

一个自然的疑问是：既然已经有了后量子算法，为什么不干脆全部切换过去，非要跟传统算法混在一起？

答案在于信任与成熟度：

• **后量子算法还比较年轻。**ML-KEM 虽然经过了 NIST 的标准化流程，但它经受的实战攻击检验，远不如已经用了几十年的椭圆曲线密码学那么充分。万一未来发现了针对它的经典攻击（而非量子攻击），单独依赖它就会有风险。
• 混合方案相当于给同一份密钥上了两把锁。共享密钥同时由两种算法推导得出——传统的和后量子的。攻击者必须同时攻破两者才能得到密钥。
• **只要任何一种算法还没被攻破，整体安全性就成立。**这是一种"两全其反"的保险：传统算法防的是今天已知的攻击，后量子算法防的是未来的量子攻击。任何一方失守，另一方仍能兜底。
• 只要其中一个组成部分仍然安全，混合设计就能保留安全性。

影响：你得到什么，又要留意什么​

你能得到什么：

• **抵御「先截获、后解密」的长期保密风险。**这是最核心的价值。
• **对端支持时自动协商启用。**TLS 握手会自行升级，无需人工干预。
• **标准的 TLS 客户端与服务端无需改动任何应用代码。**握手层面的升级对应用是完全透明的。

需要留意的地方：

• **握手报文会变大。**后量子密钥本身就比传统密钥长得多，这会让 ClientHello 报文和 key share 显著变大。
• **有些中间设备（middlebox）不喜欢过大的握手包。**老旧的防火墙、负载均衡器或深度包检测设备，可能对超出预期大小的握手包处理不好，甚至直接丢弃。
• **可以用常规的 TLS 属性来约束启用哪些 named group。**如果你的网络路径上确实存在这类问题，可以用标准的 TLS 配置手段来限制或调整协商的 named group，而不需要改动应用逻辑。

结论​

Java 27 让你的 TLS 连接默认就具备后量子防护。"先截获、后解密"不是一个遥远未来的假想威胁，而是一个此刻就应当认真对待的现实风险——尤其对那些需要长期保密的数据而言。而应对它所需要做的，仅仅是升级 JDK。安全性的提升，就藏在一次寻常的版本升级里。