JEP 527 targets JDK 27 for hybrid TLS key exchange. • Bouncy Castle helps with controlled non-TLS pilots. • Inventory and crypto-agility work run on any JDK version — start today. • Start with inventory, then one safe pilot.
period 2026 HNDL attack Q-day 2036 Data protected using RSA/ECC- based key exchange or key wrapping Q-day: cryptographically relevant quantum capability
establishment • FIPS 204: ML-DSA for digital signatures • FIPS 205: SLH-DSA for digital signatures • The standards exist, but migration still needs engineering work.
numbers directly. Compare the planning signal. Technical references (planning baseline): • 2019 RSA-2048 estimate: ~20M noisy qubits, about 8 hours • How to factor 2048-bit RSA integers in 8 hours using 20 million noisy qubits – Quantum • 2025 RSA-2048 estimate: <1M noisy qubits, under a week • [2505.15917] How to factor 2048-bit RSA integers with less than a million noisy qubits ----- Public-context footnote (NOT a planning baseline): • Live Science headline about a 10,000-qubit scenario under specific assumptions NOTE: These estimates use different hardware, architecture, logical-qubit, noisy-qubit, and error-correction assumptions. They are not deployed systems.
show the same gap. DigiCert, 2025 Press release: 8 May 2025 / n=1,042 (US/UK/AU) 69% recognise the quantum threat. 5% have deployed quantum- safe encryption. PwC, 2025/2026 -Global Digital Trust Insights Survey: May–Jul 2025 / n=3,887 (72 countries) 3% <10% have implemented all leading quantum- resistant measures. prioritise quantum risks in budgets. Quantum is among the top five least-prepared threats. 46% report substantial data vulnerable to HNDL.
dates United States NSA CNSA 2.0 / CNSSP-15 National Security Systems • Staged transition towards 2035 European Union Recommendation (EU) 2024/1101 and EU PQC Roadmap Member States, public administrations, and critical infrastructures • Foundations by end-2026 • High-risk systems by end-2030 • Broader transition by end-2035 United Kingdom NCSC PQC migration timelines Organisations, especially large and critical systems • Discovery and initial plan by 2028 • Early highest-priority migration by 2031 • Complete PQC migration by 2035 Japan Cabinet Secretariat interim summary (FY2026 roadmap planned) Government agencies • Aim in principle to migrate to PQC by 2035
signatures by NIST from 2011 • Removed from public-web TLS certificates by 2017 but still used in 2020. • PQC will be harder. • Mathematics, key sizes, and protocol impact all change. Starting now is realistic, not pessimistic.
JDK 27: • hybrid TLS 1.3 through javax.net.ssl. • JDK 27 early-access builds make hybrid TLS testable. • The IETF hybrid TLS work is still moving: • check the target draft/RFC version before production rollout. • Some client libraries already provide opt-in support. • e.g. AWS SDK for Java 2.x exposes .postQuantumTlsEnabled(true) on the CRT (Common Runtime) HTTP client. • Most other Java client libraries are not enabled by default — check vendor docs. • Practical shift: Which service can we test safely first?
long time. • They use TLS, JWT, keystores, libraries, and providers. • Infrastructure changes alone are not enough. • Application integration still matters.
452: KEM API Java 24 • JEP 496: ML-KEM • JEP 497: ML-DSA Java 25 • JEP 510: Key Derivation Function API JDK 27 target • JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3
is becoming testable Feature Practical path Java 21 KEM API (JEP 452) Use it for design checks and inventory work. Use providers for real PQC algorithms. Java 24 ML-KEM (JEP 496) ML-DSA (JEP 497) Start serious non-TLS pilots if Java 24+ is possible. Java 25+ KDF API (JEP 510) Use it for new key-derivation work, not as a TLS migration by itself. JDK 27 target Hybrid TLS 1.3 (JEP 527) Hybrid TLS 1.3 is testable through JSSE. Plan named-group and peer-interoperability tests. Migration lesson Start with platform and provider capability, and do not start with hand-written crypto code. # SLH-DSA has no OpenJDK JEP yet. Use regular Bouncy Castle only for controlled SLH-DSA pilots. (BC regular 1.80+)
targets hybrid TLS 1.3 through javax.net.ssl APIs. • For TLS 1.3 key exchange, standard JSSE applications can benefit without app-code changes when peers support the selected hybrid group, and the application does not pin named groups. Default behaviour in JDK 27 EA builds: • X25519MLKEM768 is offered first in the default named-group list. • Classical groups such as x25519 and secp256r1 remain as fallbacks. New hybrid groups added by JEP 527: • X25519MLKEM768 (default-enabled, preferred) • SecP256r1MLKEM768 (available by explicit named-group configuration) • SecP384r1MLKEM1024 (available by explicit named-group configuration)
3. Each side derives both shared secrets, then concatenates them: ML-KEM || X25519 🖥 Client 🌐 Server 2. ServerHello selects the group and returns a hybrid key share 4. HKDF takes that one combined input and derives the handshake secret 1. ClientHello offers a hybrid group (e.g. X25519MLKEM768) For X25519MLKEM768: K_combined = K_MLKEM ||" K_X25519 Note: The exact order is group-specific. For the NIST-curve hybrid groups, ECDHE comes first.
one waterfall. 1. Inventory: find crypto and secrecy lifetime. 2. Prioritise: rank by exposure, lifetime, and owner. 3. Prepare: make algorithms and providers configurable. 4. Pilot: start with one TLS service using hybrid key exchange. 5. Expand: monitor, document exceptions, and update policy. (Inventory and code prep can run in parallel from day one.)
in through libraries or drivers? Source and frameworks • Where does the application ask for crypto? Config, KeyStore, TrustStore • What enables crypto with almost no Java code? Runtime capability and evidence • What the JVM could use, and what did it actually use under real traffic?
often hidden behind framework APIs. 🔴 Spring Security: NimbusJwtEncoder signs JWTs with RSA. 🟡 Bouncy Castle: JcaContentSignerBuilder takes the signing algorithm as an argument. 🟡 Spring Boot: server.ssl.* enables TLS with almost no Java code. Keyword grep alone is not enough. • Read framework configuration and builder calls.
the full TLS story 🔴 RSA-2048 server key 🔴 RSA-signed certificate chain • Used for HTTPS authentication in this service • Same keystore is also referenced by JWT and licence flows in this demo • Needs review for certificate and signature migration • Does not prove the negotiated TLS named group
different. Outside the JVM: Edge TLS / Managed crypto / External identity Capability What can the platform offer? SSLContext.getDefault().getSupportedSSLParameters().getCipherSuites() or, per sockets: sslSocket.getSupportedSSLParameters().getNamedGroups() Configuration what did you actually ask for? SSLParameters.setNamedGroups(..."") -Djdk.tls.namedGroups=..."" Runtime What really happened in the JVM? JFR: jdk.TLSHandshake / jdk.X509Certificate / jdk.SecurityProviderService (since JDK 20) Clear named-group proof: JSSE debug (-Djavax.net.debug=ssl:handshake:verbose) or packet capture:
small service: 22 crypto touchpoints. • Most were not obvious from business code. Quantum vulnerable Need review Low risk Total 5 14 3 22 (in this demo)
long-lived confidential data. • Do not treat every TLS endpoint as the same priority. • Then review long-lived encrypted data and key-wrapping paths. • Move high-trust signatures on a separate authenticity timeline.
(JEP 527 default): • The client can offer a hybrid key share and a classical X25519 key share. • The server selects one negotiated group. • Authentication is a separate track: • Certificates, JWT signatures, and S/MIME signatures. • Breaking these later enables impersonation, but it does not decrypt past passive TLS captures by itself. If X25519MLKEM768 is selected, this session uses a hybrid key exchange: classical X25519 + ML-KEM-768. That protects this session against a future quantum break, as long as one side of the hybrid design remains secure. Sessions recorded before you ship hybrid TLS stay at risk.
one TLS 1.3 handshake. • Use pure PQC key exchange only where you control both ends and the protocol stack supports it. • Hybrid is the practical transition path for open ecosystems. • It is not the same as a pure PQC end state. • Consider exiting hybrid key exchange only when: • pure PQC TLS groups are standardised and implemented, • all peer clients and servers support them, • middleboxes and clients tolerate the larger handshake, • vendor support windows line up. • Certificate and signature migration is tracked separately.
• Today — encryption track: • Move hybrid key exchange first for HNDL protection. • Today — signature / PKI track (private PKI or controlled ecosystem only): • Pilot PQC certificates, composite certificates, or dual-certificate approaches. • Test trust stores, chain validation, certificate size, client and gateway compatibility. • Decision rule • Controlled ecosystem ➡ experiment now. • Open / public web ➡ wait for the ecosystem. • Practical advice • Not a near-term recommendation for the public web.
(for example, AES-GCM). • Post-quantum impact is mainly in the TLS handshake. • In JDK 27 (JEP 527), the client can offer X25519MLKEM768, which carries classical and ML- KEM key material together for hybrid key exchange. • The server responds with the single negotiated group. • Main rollout risks are middleboxes, MTU/fragmentation, and compatibility. Item Classical (X25519) JEP 527 default ClientHello key_share 32 bytes 1,248 bytes (1,216 + 32) (1,216 X25519MLKEM768 + 32 x25519 fallback) ServerHello key_share 32 bytes 1,120 bytes (1,088 + 32) ML-KEM ciphertext + X25519 share Shared-Secret Input to HKDF 32 bytes 64 bytes (32 + 32) ML-KEM shared secret || X25519 shared secret
significantly harder than TLS 1.3. Three practical blockers • Cipher-suite rigidity • Larger handshake messages and middleboxes • New hybrid key-exchange work is focused on TLS 1.3 Practical advice Upgrade to TLS 1.3 first, then add hybrid TLS.
• Put policy in configuration. • algorithm chosen by config, not by string literal • Keep provider out of business code. • delegate to a narrow adapter • Test changes before production. • algorithm switch should be a config change, not a code change • Always keep rollback ready. • previous algorithm string in config, easy revert
Config controls the policy; business code stays stable. Move algorithm and key material together: "SHA256withRSA” + RSA key ⬇ "ML-DSA-65” + ML-DSA key Keep business code on a standard JCA call Signature.getInstance( config .getSignatureAlgorithm() ) Let the provider resolve the algorithm (JDK or BC). For BC-based PQC pilots - Register the provider once. - Keep BC-specific logic in one small adapter. Choose the parameter set explicitly: ML-DSA-44 / -65 / -87 (FIPS 204) Business code stays the same. Policy, provider, and key material move together.
mode: classical message-protection: cms-smime-mode: classical-baseline provider: BC content-cipher: AES/GCM/NoPadding key-wrap: RSAES-OAEP oaep-digest: SHA-256 oaep-mgf: MGF1 oaep-mgf-digest: SHA-256 oaep-label: empty pqc-pilot-target: ML-KEM-based CMS recipient flow when provider and peers are ready legacy-verify-allowed: true Configuration – e.g. application.yml Keep four things in configuration: 1. Separate modes by migration track 2. Use standard names and complete transformations 3. Keep TLS named-group order outside code 4. Keep message-protection provider and policy outside code
is first in the default named-group list in JDK 27 EA builds. • Override named group order only when you need to. • JVM-wide: -Djdk.tls.namedGroups=X25519MLKEM768,x25519 • Per-connection: SSLParameters::"setNamedGroups(..."") Earlier JDKs • Hybrid TLS pilots are provider-specific. • Test the exact provider version, draft/RFC behaviour, and interoperability. For non-TLS PQC pilots: • use the BC general provider only where you control the ecosystem.
TLS path • Best for public web and mobile systems • Faster change, narrower blast radius Inside-out (trust-core-first) • First step: map internal trust dependencies and controlled service-to-service domains • Best for tightly controlled internal ecosystems • Slower change, broader coordination
• The TLS record-layer AEAD, such as AES-GCM or ChaCha20-Poly1305, still protects application data. • Handshake impact usually comes from: • larger key shares • network behaviour • provider and hardware behaviour • Still measure: • CPU and memory per handshake • p50 and p95 handshake latency under real traffic • connection-reuse rate, because reused connections reduce handshake cost
can you prove the named group? • Performance: what is the handshake cost and latency? • Rollback: can you go back safely? • Policy: can you see failures clearly?
not automatically remove implementation leakage. • Implementation risk remains • Timing • Cache • Power • Branch-dependent behaviour, etc. • Practical rule • Use reviewed providers. • Avoid roll-your-own primitives. • Use validated modules or hardened boundaries for high-risk systems. Question to ask your provider: “Are ML-KEM and ML-DSA implementations constant-time, and for which version and platform?”
• many services are still on older Java versions • crypto ownership is spread across teams • 60%+ of crypto sits outside the security module • 3,000+ touchpoints: manual review does not scale. 2025 2026 2027 2028 2029 2030 Discover inventory and ownership Protect priority paths hybrid TLS for priority paths Expand trust controlled certificate and message-level pilots Retire legacy remove old algorithms after confidence is earned JDK 27 GA is currently targeted for September 2026 (planning milestone, not a dependency guarantee).
to remember 1. Inventory first: you cannot migrate what you cannot find. 2. Hybrid TLS is usually the first practical HNDL move where JDK 27 fits. 3. Start small: one service, four evidence layers, one owner. Start this week • Run keytool -list -v on one real service keystore, and mvn dependency:tree on one real service. • In staging or an isolated test client, test -Djdk.tls.namedGroups=X25519MLKEM768,x25519 on JDK 27 EA. • Choose one message-level flow: S/MIME, CMS, or JWT signing.
logico_jp
oikon48
thousanda
oracle4engineer
ham0215
8maki
nagatsu
line_developers_tw
personabb
ebiken
zozotech
aleyda
trallard
kimpetersen
lara
gr2m
bluesmoon
tonyrice
mclloyd
mfonobong
danielanewman
427marketing
![tls: key-exchange-mode: hybrid named-groups: [X25519MLKEM768, x25519] certificates: mode: classical application-signatures:](https://files.speakerdeck.com/presentations/0695a16db1794f4dbadee0b46e5a0bc7/slide_48.jpg){kind=link}
