From Theory to Practice: Post-Quantum Cryptography Migration NISHIKAWA, Akihiro (Aki) Cloud Solution Architect, Microsoft 

Olá! こんにちは! Hello! { "name": "NISHIKAWA, Akihiro", "nationality": "Japan", "work": "Microsoft", "favourites": [ "JVM", "GraalVM", "Azure" ], "expertise": [ "Application integration", "Containers", "Serverless" ] } 

Agenda • Why PQC matters now • What Java teams need to know • How to migrate without breaking production • Key principles and your first steps 

TL;DR • Your first migration problem is hidden crypto. • 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. 

Why PQC matters now 

No cryptography stays safe forever. 

10-year retention period 2036 End of retention period 2026 Data protected using RSA/ECC- based key exchange or key wrapping 

"Harvest Now, Decrypt Later" (HNDL) Attackers can capture encrypted data today and keep it for later decryption. 

If Q-Day happened in the retention period... End of retention period 2026 HNDL attack Q-day 2036 Data protected using RSA/ECC- based key exchange or key wrapping Q-day: cryptographically relevant quantum capability 

The simple risk model Q1: Does the data need to stay secret for more than five years? Q2: Does it cross a network you do not fully control? 

What is PQC? • Post-Quantum Cryptography runs on normal computers. • It is designed to resist known attacks from large-scale quantum computers. • ML-KEM: key establishment • ML-DSA and SLH-DSA: digital signatures 

What is already standardised? • FIPS 203: ML-KEM for key establishment • FIPS 204: ML-DSA for digital signatures • FIPS 205: SLH-DSA for digital signatures • The standards exist, but migration still needs engineering work. 

Quantum-attack resource estimates keep moving down Do not compare the 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. 

Awareness is high, but deployment is lagging Two independent surveys 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. 

Global government timelines for PQC migration Region Roadmap Scope Target 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 

Cryptographic migration takes time • SHA-1 example • Deprecated for 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. 

2026 PQC highlights for Java teams • JEP 527 targets 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? 

Why Java applications are exposed • They live for a long time. • They use TLS, JWT, keystores, libraries, and providers. • Infrastructure changes alone are not enough. • Application integration still matters. 

What Java teams need to know 

Evolution of PQC support in Java Java 21 • JEP 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 

Java PQC support What you can use today, and what 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+) 

JDK 27 target: what JEP 527 gives you JEP 527 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) 

Java and Post-Quantum Cryptography – Inside.java https://inside.java/2026/04/08/javaone-post-quantum-cryptography/ Sean Mullan 

Hybrid TLS 1.3: X25519MLKEM768 Only what you need to know 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. 

Important boundary • JEP 527 targets TLS key exchange in JDK 27. • It does not automatically migrate certificates, JWT, S/MIME, CMS, document signing, or code signing. • Treat those as separate tracks. 

Bouncy Castle: where it fits • Useful for non-TLS PQC pilots • e.g. CMS, S/MIME, message protection, application signatures • Required: • BC regular 1.80+ for non-TLS APIs (KeyPairGenerator, Signature, KEMRecipientInfo) • BCJSSE 1.81+ for hybrid TLS (X25519MLKEM768) • Key APIs: • KeyPairGenerator.getInstance("ML-KEM-768") • Signature.getInstance("ML-DSA-65") • KEMRecipientInfo (RFC 9629 in CMS API) • Caveat: • BC-FIPS does not yet include ML-KEM / ML-DSA. • For FIPS-validated environments, check the BC-FIPS changelog before planning a non-TLS PQC pilot. 

How to migrate without breaking production 

How to migrate without breaking production Five work items, not 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.) 

Inventory Find where crypto is used: • TLS endpoints, named groups, mTLS, certificate stores • JWT, OIDC, SAML, code signing, and JAR signing • Custom cipher use and data-at-rest encryption • Dependencies, configuration, KeyStore, TrustStore • Sensitive data and required secrecy lifetime 

A four-layer inventory for Java Dependencies • What crypto comes 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? 

Demo: where crypto hides How many crypto touchpoints are hiding? • A small Spring Boot service • JWT service • encryption service • licence service • application.properties / yml • keystore.p12 src/main ├── java/com/example/pqcdemo │ ├── config │ │ └── SecurityConfig.java │ ├── controller │ │ └── ApiController.java │ ├── PqcDemoApplication.java │ └── service │ ├── EncryptionService.java │ ├── HmacService.java │ ├── JwtService.java │ └── LicenseService.java └── resources ├── application.properties └── keystore.p12 

Demo • Layer 1: dependencies • Layer 2: source and frameworks • Layer 3: configuration and keystores • Layer 4: runtime capability and evidence 

What the audit finds - dependencies • Review first • JWT signing libraries • database drivers using TLS • general-purpose crypto providers 🔴 Quantum-vulnerable as used 🟡 Needs review 🟢 Low-risk 🔴 Nimbus JOSE+JWT used here for RSA (RS256) JWS 🟡 Bouncy Castle General-purpose crypto provider 🟡 Google Tink Algorithm hidden in key template 🟡 Spring Security BCrypt, crypto utilities 🟡 PostgreSQL JDBC TLS via driver configuration - easy to miss in code review 🟢 Commons Codec Hashing/encoding utilities 🟡 JDK built-in JCA/JCE Always available 

What the audit finds - source and configuration Crypto is 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. 

What the audit finds – KeyStore Quantum-vulnerable material, but not 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 

Layer 4 Needs Three Views Support, configuration, and evidence are 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: 

What the audit finds – JFR runtime audit • Static analysis can miss runtime-only crypto behaviour. • Enable these JFR events (custom .jfc; not in default.jfc / profile.jfc) • Capture with jcmd JFR.start or a recording template. Events Helps with jdk.TLSHandshake TLS protocol version, cipher suite, peer, and certificate id jdk.X509Validation certificate-chain validation jdk.X509Certificate certificate inventory: subject, issuer, signature algorithm, key type, key size, validity jdk.SecurityPropertyModification security-property changes jdk.Deserialization deserialization-related security events jdk.SecurityProviderService provider, service type, and algorithm lookup 

How to prove hybrid TLS in practice • Built-in runtime evidence: JDK Flight Recorder (JFR) / JDK Mission Control • TLS handshake event • jdk.TLSHandshake: protocol version, cipher suite, peer host and port, certificate id • Certificate evidence • jdk.X509Certificate: subject, issuer, signature algorithm, key type, key size • jdk.X509Validation: certificate-chain validation • Provider evidence • jdk.SecurityProviderService: service type, algorithm, provider • Clear named-group proof • JSSE handshake debug: look for supported_groups and ServerHello KeyShare. • -Djavax.net.debug=ssl:handshake:verbose • Packet capture: Wireshark can show supported_groups and key_share • Custom audit event: use only if your TLS layer or proxy can expose the negotiated group. 

Demo result — one small Spring Boot service • One 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) 

What should move first? • Start with transit paths carrying 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. 

Why HNDL targets key exchange, not authentication • ClientHello key_share (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. 

Hybrid means safer transition • Hybrid: classical + ML-KEM in 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. 

PKI certificate migration Keep encryption and signatures on separate tracks. • 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. 

What changes in TLS? • Record-layer encryption stays the same (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 

Why is hybrid hard on TLS 1.2? Not impossible, but 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. 

Crypto-agility in plain words • Don't hard-code algorithms. • Signature.getInstance(config.getSignatureAlgorithm()) • 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 

Bad pattern //" algorithm and provider – both fixed at compile time sig = Signature.getInstance("SHA256withRSA"); KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA", "SunRsaSign"); 

Better pattern Config controls the policy; business code stays stable. 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. 

tls: key-exchange-mode: hybrid named-groups: [X25519MLKEM768, x25519] certificates: mode: classical application-signatures: 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 

TLS configuration JDK 27 / JEP 527 default • X25519MLKEM768 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. 

Phased approach — two dimensions What to move first key exchange or authentication? Where to start edge or trust core? 

Topology comparison Outside-in (edge-first) • First step: upgrade the edge 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 

• Roll out hybrid TLS in phases, while keeping backward compatibility. • Phase 1 (edge): enable hybrid TLS at CDN/proxy/gateway edges. • Phase 2 (backend): move Java services behind the edge to hybrid-capable stacks. • Phase 3 (targeted end-to-end): extend further only where client/partner ecosystems are ready. • Keep certificate pilots (PQC, composite, or dual-certificate) only in controlled ecosystems. Outside-in: 3 phases Backends Java app CDN/Proxy Client Hybrid TLS Classic TLS Hybrid TLS Classic TLS Hybrid TLS Classic TLS 

Performance and operational impact on TLS • Bulk cipher unchanged • 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 

Testing strategy • Interop: can both sides connect? • Evidence: 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? 

Side-channel reminder • PQC changes the mathematics. • It does 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?” 

Migration timeline – anonymised customer-project composite Why it took longer: • 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). 

Top blockers and practical responses • Network path: test real routes. • Keys and certificates: start where you control both ends. • Vendors: ask early. • Operations: capture evidence and prepare rollback. 

Key principles and your first steps 

Three things to remember & Start this week Three things 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. 

Muito obrigado! ありがとう! Thank you!