Java 27后量子加密默认生效 政企密码迁移路线图

一、事件：Java 27把后量子加密放进默认配置

2026年9月15日，Oracle正式发布JDK 27，这一非LTS版本包含9项JEP，安全相关的改动最受关注：TLS 1.3引入后量子混合密钥交换并默认启用，标准库中ML-KEM与ML-DSA的私钥编码格式更新、算法性能显著提升，还新增了在运行时查看当前生效安全属性的命令。

相比语言层面的语法演变，这次的密码改动看起来低调，但对存量系统影响更直接：Java 27是非LTS版本，Oracle同时把后量子能力回移到受支持的LTS版本，意味着企业不必等到下一次大版本升级才能获得抗量子能力。

换句话讲，从今年起新建的Java应用、中间件与网关，只要升级运行时就能在链路层使用后量子混合密钥交换，而老系统则需要额外的评估与测试。这对安全团队提出了一个很现实的问题：密码算法的更换周期远长于软件版本，能不能提前排上日程，取决于今天有没有做清点。

二、为什么现在必须动：先存后解的现实压力

推动这件事的并不是厂商的热情，而是攻击方式的现实。所谓“先存储、后解密”，是指攻击者今天把加密流量或加密文件抓走存起来，等量子计算机具备破解能力后再回头解密。

对保密期长的数据，这个窗口正好落在当下：政务档案、医疗影像、户籍与身份信息、测绘与工程设计资料，往往需要保密十年以上，今天被截获的密文，几年后就会变成明文。

行业数据也说明服务端并没有跟上。Cloudflare披露，其自动密钥交换机制已在每天约450亿次源站握手中按对方能力选择算法，HelloRetryRequest的比例从约52%降到3.7%，握手延迟的p90值减少150毫秒以上；对支持后量子算法的源站，单次往返完成握手比例从0%提升到99.2%。但同一组数据里最值得注意的数字是12.8%——目前只有约一成多的源站支持后量子密钥交换。客户端、浏览器和CDN已经跑在前面，真正没换的，是大多数企业自己机房里的那一端。

这也解释了为什么密码迁移很难只靠软件厂商推动：只有把自建系统的加密配置改到位，整条链路才算真正抗量子。

三、迁移五步：从清点开始，别只盯TLS

对已经在跑Java应用的团队来说，可以把迁移拆成五步走。

① 密码资产清点：不只是HTTPS，还包括服务间双向认证、代码与固件签名、VPN、SSH、数据库字段加密、加密机与证书管理系统。列出每处用到的算法与密钥长度，才能算出工作量。

② 数据分类与优先级：保密期长的数据优先迁移，短期数据排在后面，把有限的预算用在几十年内都不能外泄的那批数据上。

③ 混合模式过渡：X25519MLKEM768这类把经典算法与后量子算法叠加的方案，即使新算法被证明存在缺陷，安全性也不会低于现状，是目前最稳妥的起点。

④ 兼容与性能回归：后量子公钥与密文体积明显变大，握手报文可能超过MTU触发分片，证书链与会话票据同样变大；需要验证老客户端、老中间件、老加密机是否受影响，并准备降级开关。

⑤ 管理流程同步更新：加密机固件、证书模板、签名算法白名单与审计日志的算法字段都要一起改，避免出现“应用已支持、设备不支持”的悬空状态。

四、对青海政企的落地建议

对青海省内的政企单位来说，后量子迁移不必另起一套体系，直接挂靠在现有的等保与密码应用机制上更现实。等级保护2.0对通信传输、数据存储的密码要求，以及《信息安全技术 信息系统密码应用基本要求》（GB/T 39786-2021）配套的商用密码应用安全性评估，已经把密码合规纳入常态动作，算法选型与清点工作完全可以并入其中。

具体可以先做两件低成本的事。第一，请运维把对外发布系统、VPN、加密设备型号与固件版本列成一张清单，标出哪些位置在用RSA或经典椭圆曲线算法；第二，向主要设备与软件厂商书面确认后量子支持路线，包括是否计划支持ML-KEM与ML-DSA、大致时间表、是否需要更换硬件。这两件事的结果，直接决定未来三年的预算规模，也决定今年采购时要不要在合同里写明算法要求。

另外三个提醒：一是长期保密数据最值得提前保护，档案、医疗影像、测绘与工程设计资料可以在新建系统与归档系统中先试点混合密钥交换；二是加密设备属于长周期资产，采购时把后量子算法支持写进技术要求，能避免三年内二次改造；三是不必为“量子”概念支付过高溢价，现阶段真正有效的工作是清点与混合过渡，而不是立刻全量替换。

密码算法迁移是一件周期以年计的工程，不会因为某次版本发布而自动完成。Java 27把后量子密码带进了默认配置，等于把起点提前了；接下来真正拉开差距的，是有没有单位在本季度就把自己用了哪些算法这件事弄清楚。