Preparing Java Applications for the Quantum Era

JavaLand 2026

Transcript

1. Preparing Java Applications for the Quantum Era NISHIKAWA, Akihiro (Aki) Cloud Solution Architect, Microsoft @logico_jp @logico-jp.dev linkedin.com/in/anishi1222/
2. Hallo! こんにちは! Hello! { "name": "NISHIKAWA, Akihiro", "nationality": "Japan", "work": "Microsoft", "favourites": [ "JVM", "GraalVM", "Azure" ], "expertise": [ "Application integration", "Container", "Serverless" ] }
3. Agenda  Problem & Urgency  PQC support in Java  Migration Strategy  Takeaways & Call to Action
4. TL;DR Quantum threat is Real. Java is getting ready for PQC. The sooner, the better.
5. Problem & Urgency
6. No cryptography stays safe forever.
7. 10-year retention period 2036 End of retention period 2026 Data protected with RSA/ECC
8. Harvest-Now, Decrypt-Later (HNDL) Attack Malicious attackers have captured encrypted data to decrypt it when quantum computers emerge. 2030+ Quantum computer emerges 2036 End of retention period HNDL attack 2026 Data protected with RSA/ECC
9. If “Q-Day/Y2Q” happened in the retention period... Q-Day.org - Q-Day, Y2Q, PQC, Quantum Readiness, Quantum Security 2030+ Quantum computer emerges 2036 End of retention period Q-Day HNDL attack 2026 Data protected with RSA/ECC
10. Post-Quantum Cryptography (PQC)  New cryptographic algorithms designed to be secure against quantum attacks.  Based on math problems that quantum computers (as far as we know) cannot solve efficiently, such as  lattice problems (e.g.; ML-KEM, ML-DSA)  hash-based structures (e.g.; SLH-DSA)  error-correcting codes (e.g., HQC), etc.  No quantum hardware is needed.  These algorithms run on classical computers.
11. Why sooner actions needed?
12. The Quantum Computer Breakthrough How many noisy qubits are needed to break RSA-2048? Research by Craig Gidney and Martin Ekerå How to factor 2048-bit RSA integers in 8 hours using 20 million noisy qubits – Quantum Estimated in 2019 20M Re-estimated in 2025 <1M Research by Google’s Quantum AI team (Craig Gidney) [2505.15917] How to factor 2048-bit RSA integers with less than a million noisy qubits
13. Awareness is high, but deployment is lagging 65% of orgs are concerned about HNDL attacks. (Capgemini, Jul 2025) 69% of orgs believe quantum computing will break encryption within 5 years. (DigiCert, May 2025) expect to have at least one PQC algorithm operational by the end of 2026. (Trusted Computing Group, Nov 2025) 20% 5% 55% of orgs have begun PQC migration (Utimaco, 2025) have fully deployed quantum-safe encryption. (DigiCert, May 2025)
14. Government Deadlines ~2035 Full transition of national security systems ~2035 Achieve full implementation ~2035 Full transition target ~2035 Full transition target (estimated) ~2030 Ensure quantum resistance for confidential data
15. For example, it took many organizations over five years to migrate from the vulnerable primitive SHA-1 to its secure successor SHA-256, even after the necessary specifications and implementations were available. (e.g., SHA-1 deprecated 2017; many systems still used it in 2020+) – The PQC Migration Handbook Cryptographic migration takes time
16. Industry Movement Cloud services Major cloud providers are already rolling out support for PQC. Browsers Default to hybrid post-quantum TLS. Libraries OpenSSL 3.5.0 and later supports PQC algorithms. CDN Over 50% of Cloudflare’s traffic by human uses PQC encryption.
17. Can we use PQC today?
18. FIPS for PQC Approved and Effective Approved in August 2024 ML-KEM FIPS 203 ML-DSA FIPS 204 SLH-DSA FIPS 205 • CRYSTALS-Kyber based • Module Lattice based Key Encapsulation Mechanism • Key establishment • CRYSTALS-Dilithium based • Module Lattice based Digital Signature Algorithm • Digital signatures • SPHINCS+ based • StateLess Hash- based Digital Signature Algorithm • stateless hash- based signatures Post-Quantum Cryptography FIPS Approved | CSRC
19. More standards coming Post-Quantum Cryptography | CSRC HQC (not yet but will be FIPS-207) FN-DSA FIPS-206 • A backup algorithm for ML- KEM • Hamming Quasi-Cyclic • Code-based key exchange mechanism • FALCON based • FFT (fast-Fourier transform) over NTRU-Lattice-Based Digital Signature Algorithm NIST Selects HQC as Fifth Algorithm for Post-Quantum Encryption | NIST AMS :: Feature Column from the AMS CSRC Presentations: FIPS 206: FN-DSA (Falcon) | CSRC Falcon
20. Why Are Java Applications at Risk? Live for a long time. Use crypto everywhere. Not just an infra problem, integration needed. Security risk Business risk Late adoption woes Cost & effort
21. PQC support in Java
22. Java PQC Timeline A timeline of Java (JDK) releases and their post-quantum crypto features: JEP 452: KEM API (Key Encapsulation Mechanism) # No PQC algorithms included (APIs only) Java 21 Sep 2023 JEP 496: ML-KEM JEP 497: ML-DSA Java 24 Mar 2025 JEP 510: Key Derivation Function API Java 25 Sep 2025 RFC 9180 compliant Hybrid Key Encryption algorithm (Cipher “HPKE”) (JDK-8325448) Signed JAR Support for ML-DSA (JDK-8349732) Java 26 Mar 2026
23. ML-KEM Key Exchange Key exchange using ML-KEM // Example: use ML-KEM-768 as the default KeyPairGenerator g = KeyPairGenerator.getInstance("ML-KEM"); KeyPair kp = g.generateKeyPair(); // Encapsulate a secret with the public key (sender side) KEM kem = KEM.getInstance("ML-KEM"); KEM.Encapsulator encap = kem.newEncapsulator(kp.getPublic()); KEM.Encapsulated capsule = encap.encapsulate(); // Agreed secret key and send these bytes to other party SecretKey sharedSecret = capsule.key(); byte[] encapsulatedBytes = capsule.encapsulation(); // Decapsulate on the other side using private key (receiver side) KEM.Decapsulator decap = kem.newDecapsulator(kp.getPrivate()); SecretKey sharedSecret2 = decap.decapsulate(encapsulatedBytes);
24. ML-DSA Digital Signature Digital signing and verification using ML-DSA // Generate ML-DSA (Dilithium) key pair KeyPairGenerator kpg = KeyPairGenerator.getInstance("ML-DSA"); // ML-DSA-65 key pair as the default KeyPair sigPair = kpg.generateKeyPair(); byte[] data = "Important message".getBytes(StandardCharsets.UTF_8); Signature sig = Signature.getInstance("ML-DSA"); sig.initSign(sigPair.getPrivate()); sig.update(data); byte[] signature = sig.sign(); // ...transmit 'data' and 'signature'... // Verification sig.initVerify(sigPair.getPublic()); sig.update(data); boolean valid = sig.verify(signature);
25. Bouncy Castle (BC) https://www.bouncycastle.org/  Comprehensive PQC support ahead of the JDK.  BC 1.79 (the latest is 1.83) or later implement ML-KEM, ML-DSA, as well as SLH-DSA (SPHINCS+), HQC, and Falcon.  Can use all NIST finalists (and some alternates) on Java 8, 11, 17, etc., via Bouncy Castle.  Integration via JCA Provider  To use BC’s PQC, register the provider and request algorithms by name and provider: import java.security.Security; import org.bouncycastle.jce.provider.BouncyCastleProvider; Security.addProvider(new BouncyCastleProvider()); ... // The JCA will pick Bouncy Castle in the list KeyPairGenerator kpg = KeyPairGenerator.getInstance("ML-DSA", "BC");
26. What about TLS?
27. JEP 510: Key Derivation Function API JEP 496: ML-KEM JEP 497: ML-DSA Java PQC Timeline A timeline of Java (JDK) releases and their post-quantum crypto features: JEP 452: KEM API (Key Encapsulation Mechanism) # No PQC algorithms included (APIs only) RFC 9180 compliant Hybrid Key Encryption algorithm (Cipher “HPKE”) (JDK-8325448) Signed JAR Support for ML-DSA (JDK-8349732) Java 21 Sep 2023 Java 24 Mar 2025 Java 25 Sep 2025 Java 26 Mar 2026 Java 26 has not incorporated PQC into the JSSE standard TLS.
28. Java PQC Timeline A timeline of Java (JDK) releases and their post-quantum crypto features: Java 24 Mar 2025 Java 25 Sep 2025 Java 26 Mar 2026 JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3 (target, Completed) # Default JSSE will cover these algorithms in TLS. Java 27 Sep 2026 Java 26 has not incorporated PQC into the JSSE standard TLS.
29. Current Limitations & Gaps • JEP 527 is integrated and completed in Java 27!! • Post-Quantum Hybrid Key Exchange for TLS 1.3 • Current default JSSE doesn’t cover PQC in TLS. (JSSE provider can be added to support PQC enabled TLS.) Java Secure Socket Extension (JSSE) Reference Guide • ML-KEM and ML-DSA are available in JDK 24/25/26 APIs.
30. Migration Strategy
31. Migration Strategy 1. Inventory 2. Prioritization 3. Hybrid 4. Crypto-agility 5. Where to start migration (phased approach) 6. Performance verification 7. Testing thoroughly 8. Check the timeline
32. 1. Inventory  Identify TLS endpoints, cipher suites, mTLS, cert stores.  Catalogue code/JAR signing, JWT/OIDC/SAML algorithms.  Locate custom Cipher usages and data-at-rest encryption.  Use static analysis/scanners for API/algorithm detection.  Dependency libraries  Configuration  Certificate OIDs (Object Identifiers)
33. Where Does Crypto Hide? A typical Spring Boot microservice — how many crypto usage points can you spot? 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
34. 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 _________________________JWT keys from keystore _________________________REST Endpoints _________________________RS256 via NimbusJwtEncoder _________________________AES-256-GCM via Tink _________________________HMAC-SHA256 via BC HMac _________________________CMS/PKCS#7 via BC ____________________________TLS + DB SSL config ____________________________RSA-2048 cert
35. 4-Layer Inventory ❶ Dependencies - Nimbus JWT - Bouncy Castle - Google Tink - PostgreSQL JDBC ❷ Configuration - Cipher - Signature - KeyPairGen ❸ Source code - server.ssl.* - Database SSL parameters ❹ Runtime 326 algorithms - Vulnerable: 64 - PQC: 24 (JDK 25) OMB M-23-02: Migrating to Post-Quantum Cryptography CISA/NIST/NSA: Quantum-Readiness — Migration to Post-Quantum Cryptography NIST CSWP-39: Considerations for Achieving Crypto Agility White House Report on Post-Quantum Cryptography (NSM-10 progress) 6 USC §1526: Inventory of cryptographic systems; migration to post-quantum cryptography Maven/Gradle dependency tree Properties/YAML and KeyStore JCE/JCA API and Framework API JCE providers, registered algorithms, and JVM settings
36. What The Audit Finds - Dependencies Crypto hidden in dependencies, source code, configuration, and framework APIs Nimbus JOSE+JWT JWT/JWE — RSA signing inside framework Bouncy Castle 1.83 General-purpose crypto provider Google Tink 1.9.0 Algorithm hidden in key template Spring Security 6.5 BCrypt, crypto utilities PostgreSQL JDBC TLS inside the driver — invisible Commons Codec Hashing/encoding utilities JDK built-in JCA/JCE QUANTUM-VULNERABLE ATTENTION LOW-RISK
37. What The Audit Finds - Source and Config Crypto hidden in dependencies, source code, configuration, and framework APIs JCE / JCA API Calls Signature.getInstance (Javadoc) KeyStore.getInstance (2 files) Mac.getInstance (Javadoc) Configuration server.ssl.enabled=true datasource sslmode=verify-full Framework / Library Patterns NimbusJwtDecoder (RS256) JcaContentSignerBuilder (SHA256withRSA) Tink AEAD (AES-256-GCM) Tink KeysetHandle BC CMS / SignerInfoGenerator BC HMac + SHA256Digest
38. What The Audit Finds - KeyStore Crypto hidden in dependencies, source code, configuration, and framework APIs keystore.p12  Alias: server  Type: PrivateKeyEntry  Sig: SHA256withRSA  Quantum-vulnerable Used for:  TLS server certificate  JWT signing key (RS256)  License cert verification Every HTTPS connection is a direct HNDL target because it uses RSA-2048 key exchange.
39. Audit results: 22 Crypto Usage Points 5 QUANTUM- VULNERABLE Nimbus JWT (RS256) BC ContentSigner (SHA256withRSA) Keystore cert (RSA-2048) Signature.getInstance refs 12 ATTENTION PG JDBC TLS, BC, Tink AEAD, Spring Security, KeyStore, server.ssl.*, DB SSL, CMS 5 LOW-RISK HMAC-SHA256, BC HMac, BC SHA256Digest, Commons Codec, Mac ref
40. 2. Prioritization Target Why Solution Data-in-Transit TLS VPN mTLS HNDL target TODAY Hybrid TLS (JEP 527) Data-at-Rest Database file encryption Long-lived data at risk (especially if the data is stored more than 5 years) ML-KEM key wrapping Code Signing JAR Cert license Trust, not secrecy ML-DSA (at next rotation)
41. Prioritize KEM over Signatures KEM: Key Encapsulation Mechanism KEM Communication data stolen risks being decrypted by quantum computers in the future. Exactly ‘Harvest now, decrypt later’. Signature Authentication (signature) need only remain unbroken until quantum computers become practical.
42. 3. Hybrid Combine traditional cryptography with PQC for a security net.  PQC  Resilient against quantum attacks, but with a short security verification history. (A risk to be broken).  Traditional  Long security verification history, but vulnerable to quantum attacks. draft-ietf-tls-ecdhe-mlkem - Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3 draft-ietf-tls-hybrid-design - Hybrid key exchange in TLS 1.3 JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3
43. How about direct replacement (Pure PQC)? Pros  Efficiency  Eliminates overhead of the hybrid method (though PQC keys are still larger than ECC).  Simplicity  Relying on a single cryptographic primitive reduces code complexity.  Full Compliance (Future)  Aligns with mandates like NSA CNSA 2.0. Cons  Single Point of Failure  If the PQC algorithm is broken, you're unprotected.  Incompatibility  Legacy systems lacking PQC won't connect.  Significant variation between vendors  Many current HSMs and smart cards lack hardware acceleration for PQC, slowing performance on older devices
44. Hybrid is the practical solution for a while Ultimately, pure will be the goal. Hybrid (Composite) Direct Replacement (Pure) Security Posture Classical + Quantum Resistant Quantum Resistant Only Risk of Algorithm Break Low (Classical backup exists) High (No backup) Performance Slightly lower (Dual overhead but) Medium (PQC overhead only) Primary Use Case Commercial/Civilian Transition Military/Intel (High Security) CYBER; Migration strategies and recommendations to Quantum Safe schemes Migration to Post-Quantum Cryptography | NCCoE Announcing the Commercial National Security Algorithm Suite 2.0 Avis de l'ANSSI sur la migration vers la cryptographie post-quantique (suivi 2023)
45. PKI Certificate Migration  Challenge: old vs. new clients & toolchains  Solution: hybrid/dual-signed certificates  leaf → intermediate → root  Plan for  increased sizes  update key stores/trust stores & validation logic Root CA [RSA + ML-DSA signatures] Intermediate CA [RSA + ML-DSA signatures] Leaf Certificate [RSA + ML-DSA signatures] Service (Java) draft-ietf-lamps-pq-composite-sigs - Composite ML- DSA for use in X.509 Public Key Infrastructure
46. PKI Certificate Migration  EJBCA  EJBCA 9.1 supports ML-KEM/ML-DSA certificate issuance. (Enterprise JavaBeans Certificate Authority)  AWS Private Certificate  AWS Private CA now supports post-quantum digital certificates - AWS  CA providers like DigiCert  Start to provide post-quantum and hybrid certificates for evaluation and testing, including experimental algorithms such as Falcon.  Public commercial availability depends on standards and ecosystem readiness.
47. Hybrid TLS 1.3 handshake (X25519MLKEM768) draft-ietf-tls-hybrid-design - Hybrid key exchange in TLS 1.3 Generate X25519 key pair (sk_x, pk_x = 32 bytes) Generate ML-KEM-768 key pair (dk, ek = 1184 bytes) ClientHello TLS Version: 1.3 (0x0304) Random: 32 bytes Cipher Suites: [TLS_AES_256_GCM_SHA384, ...] Extensions: supported_versions: [TLS 1.3] supported_groups: [X25519MLKEM768 (0x11EC), X25519 (0x001D), ...] key_share: [{ group: X25519MLKEM768 (0x11EC), key_exchange: pk_x (32B) ‖ ek (1184B) = 1216 bytes total }] signature_algorithms: [...] server_name: example.com Client (Key Generator + Decapsulator) Server (Encapsulator) Plaintext (unencrypted)
48. Hybrid TLS 1.3 handshake (X25519MLKEM768) draft-ietf-tls-hybrid-design - Hybrid key exchange in TLS 1.3 Generate X25519 key pair (sk_s, pk_s = 32 bytes) ML-KEM-768.Encaps(ek) → (ct = 1088 bytes, ss_pq = 32 bytes) X25519 DH(sk_s, pk_x) → ss_ecdh = 32 bytes ServerHello TLS Version: 1.3 (0x0304) Random: 32 bytes Cipher Suite: TLS_AES_256_GCM_SHA384 Extensions: supported_versions: TLS 1.3 key_share: { group: X25519MLKEM768 (0x11EC), key_exchange: pk_s (32B) ‖ ct (1088B) = 1120 bytes total } X25519 DH(sk_x, pk_s) → ss_ecdh = 32 bytes ML-KEM-768.Decaps(dk, ct) → ss_pq = 32 bytes
49. Hybrid TLS 1.3 handshake (X25519MLKEM768) draft-ietf-tls-hybrid-design - Hybrid key exchange in TLS 1.3 Shared Secret = ss_ecdh (32B) ‖ ss_pq (32B) = 64 bytes → HKDF-Extract → Handshake Secret {EncryptedExtensions} {Certificate} {CertificateVerify} {Finished} {Finished} Encrypted Application Data Client (Key Generator + Decapsulator) Server (Encapsulator) Encrypted with Handshake Keys Verify server certificate Derive Application Traffic Keys Application Data (HTTP/2, HTTP/3, etc.) Application Data
50. Size Comparison Item X25519 [Classical] (RFC 7748) X25519MLKEM768 [Hybrid] (draft-ietf-tls-ecdhe-mlkem) Delta ClientHello key_share 32 bytes 1,216 bytes (32 + 1,184) +1,184 bytes ServerHello key_share 32 bytes 1,120 bytes (32 + 1,088) +1,088 bytes Shared Secret 32 bytes 64 bytes (32 + 32) +32 bytes
51. Only nonces feed into key derivation — risks like the Triple Handshake Attack remain PQC keys are 30–50× larger — firewalls and NATs drop or truncate oversized handshakes TLS 1.2 enhancements are officially frozen — PQC work targets TLS 1.3+ only PQC KEMs need the peer's public key first — different from DH, requiring new safety analysis Static RSA mode is incompatible with PQC — passive decryption won't work either way TLS 1.2 bundles all crypto into monolithic cipher suites — hybrid combos multiply fast Why Hybrid TLS is Hard on TLS 1.2? Not impossible, but significantly harder than TLS 1.3 Weak Transcript Binding Message Size & Middleboxes IETF Feature Freeze KEM Directionality Forward Secrecy Gap Cipher Suite Explosion Upgrade to TLS 1.3 first — then add hybrid TLS
52. 4. Crypto-Agility  Involves abstracting cryptographic calls so that the underlying algorithm can be hot-swapped via configuration without rewriting application code.  Not an algorithm swap but a procedural prerequisite.
53. Why?  Resilience:  If a specific PQC standard is broken next year, you can switch to an alternative PQC candidate immediately.  Testing:  Allows you to roll out PQC to 1% of users for testing and revert instantly if issues arise.  Please note that...  Engineering Effort: Requires refactoring legacy codebases where crypto is hardcoded (e.g., hardcoded RSA-2048 keys).
54. Design Principles Don’t hard-code algorithm names or parameters Externalize choices in configuration Abstract crypto behind interfaces (strategy pattern) Leverage JCA providers to enable provider swapping Prepare fallback toggles and feature flags Config file CryptoService RSASigner Specify algorithm (ML-DSA, RSA, etc.) sign() verify() encrypt() decrypt() MlDsaSigner implements implements Signature.getInstance ("SHA256withRSA") Signature.getInstance ("ML-DSA") Interface
55. crypto: mode: hybrid # classic | pqc | hybrid # Application-Level Cryptography (KEM + Signatures) # These map directly to JCA: KEM.getInstance() / Signature.getInstance() kem: algorithm: ML-KEM-768 # JCA standard name (FIPS 203, Security Level 3) signature: algorithm: ML-DSA-65 # JCA standard name (FIPS 204, Security Level 3) tls: # Named group preference order for key exchange # JDK 27+: maps to jdk.tls.namedGroups system property # Pre-JDK 27: requires Bouncy Castle JSSE (BCJSSE) provider named-groups: - X25519MLKEM768 # PQC hybrid (recommended default) - x25519 # Classical fallback - secp256r1 # Classical NIST curve fallback protocol: TLSv1.3 # JSSE provider selection # - "SunJSSE" → JDK 27+ with JEP 527 (native PQC hybrid) # - "BCJSSE" → Bouncy Castle (JDK 24–26 workaround) provider: SunJSSE keystore: type: PKCS12 # Required for PQC keys (JKS has OID limitations) path: classpath:server-pqc.p12 password: ${KEYSTORE_PASSWORD} # PQC key aliases kem-alias: mlkem # ML-KEM-768 key pair (signed by EC signer) signature-alias: mldsa # ML-DSA-65 key pair (self-signed) Configuration application.yml
56. // crypto.kem.algorithm → KEM.getInstance() @Value("${crypto.kem.algorithm}") private String kemAlgorithm; // "ML-KEM-768" KEM kem = KEM.getInstance(kemAlgorithm); KeyPairGenerator kpg = KeyPairGenerator.getInstance(kemAlgorithm); // No NamedParameterSpec needed — parameter set is encoded in the name // crypto.signature.algorithm → Signature.getInstance() @Value("${crypto.signature.algorithm}") private String sigAlgorithm; // "ML-DSA-65" Signature sig = Signature.getInstance(sigAlgorithm); KeyPairGenerator kpg = KeyPairGenerator.getInstance(sigAlgorithm); KEM.getInstance() and Signature.getInstance()
57. // crypto.tls.provider → SSLContext.getInstance() @Value("${crypto.tls.provider}") private String tlsProvider; // "SunJSSE" or "BCJSSE" @Value("${crypto.tls.protocol}") private String tlsProtocol; // "TLSv1.3" SSLContext ctx = SSLContext.getInstance(tlsProtocol, tlsProvider); // ctx.init(keyManagers, trustManagers, null); ← keystore config omitted for brevity // crypto.tls.named-groups → SSLParameters.setNamedGroups() or system property // Option A: Programmatic (JDK 20 or later version with appropriate provider) @Value("${crypto.tls.named-groups}") private List<String> namedGroups; // ["X25519MLKEM768", "x25519", "secp256r1"] SSLParameters params = sslSocket.getSSLParameters(); params.setNamedGroups(namedGroups.toArray(String[]::new)); sslSocket.setSSLParameters(params); // Option B: JVM system property (JDK 27+ — zero code change) // -Djdk.tls.namedGroups=X25519MLKEM768,x25519,secp256r1 SSL/TLS
58. 5. Where to start migration (phased approach) Backends Java app CDN/Proxy Client Inside-Out (Core-First): The Standard Trust Chain Migration Backends Java app CDN/Proxy Client Outside-in (Gateway shield): TLS Termination Strategy
59. Summary of Topology Choices Inside-Out (Core first)  Full System Compliance  1st step: Upgrade PKI/Root CA  Complexity: High (Touches everything)  Best for Banking, Identity Systems Outside-In (Gateway Shield)  Rapid Internet Protection  1st step: Upgrade Edge Gateway  Complexity: Medium (Touches Gateway + Client)  Best for Web Apps, Mobile Apps
60. Hybrid TLS Hybrid TLS Hybrid TLS Outside-in (Gateway shield) Extend hybrid TLS gradually and hybrid certs internally with keeping backward compatibility, forward security, and modest overhead.  Phase 1: enable hybrid TLS at CDN/load balancer  Phase 2: upgrade app stack to Java which will support JEP 527  Phase 3: end-to-end PQC; retire classical ciphers where feasible Backends Java app CDN/Proxy Client Classic TLS Classic TLS Classic TLS
61. 6. Performance & Operational Impact TLS  Updating the current protocol is challenging.  Both the ClientHello and ServerHello packets get much bigger.  ClientHello packet could be fragmented at lower layers.  Unexpected behavior at intermediate switches.  The performance loss from segmentation and reassembly. Item X25519 (Classical) X25519MLKEM768 (Hybrid) Delta ClientHello key_share 32 bytes 1,216 bytes (32 + 1,184) +1,184 bytes ServerHello key_share 32 bytes 1,120 bytes (32 + 1,088) +1,088 bytes Shared Secret 32 bytes 64 bytes (32 + 32) +32 bytes
62. 7. Testing Strategy Unit Official vectors for ML-KEM/ML-DSA Interop Cross-implementation (Java  OpenSSL/liboqs) Hybrid TLS handshakes (OpenSSL 3.5 includes X25519MLKEM768 in the default KeyShare.) Performance Handshake latency CPU/memory Throughput Compatibility Fallbacks from PQC to classical Legacy clients Rollback Timing analysis on critical operations Side channel Graceful failure modes
63. 8. Migration Timeline Example: The real customer case in Japan 2025 2026 2027 2028 2029 2030 Crypto asset inventory PoC with Bouncy Castle Risk assessment Edge PQC deployment Hybrid certificates Evaluate hybrid TLS supported JDK (if released) Upgrade to hybrid TLS supported JDK/JRE Implement crypto-agility Integrate PQC Retire legacy crypto PQC-by-default operations Compliance readiness JDK 27 (Sep 2026) (including JEP 527)
64. Common Migration Challenges
65. Protocol ossification What is this? Situations where network middleboxes fail or drop connections because PQC algorithms produce keys and signatures that are much larger than the classical sizes that those devices were designed to handle. What impact? Handshake failures Mitigation / solution • Canary rollout + fallback • Hybrid mode + GREASE RFC 8701: Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility
66. Legacy client compatibility What is this? The challenge of maintaining interoperability between systems that support PQC algorithms and older clients/servers that only understand classical cryptography (RSA, ECDSA, ECDH). What impact? Breakages Mitigation / solution • Hybrid TLS/certs; staged enablement
67. Certificate size bloat What is this? Increase in X.509 certificate sizes when using PQC signature algorithms, due to their much larger public keys and signatures compared to classical algorithms. What impact? Latency/storage Mitigation / solution • TLS certificate compression • Monitor limits • For new deployments, prefer ML-DSA-65 and implement intermediate suppression.
68. Library Selection & Management Library/Tool Use Case Notes JDK 24+ Built-in PQC APIs Prefer standards JEP 527 is targeted to JDK 27 Bouncy Castle Legacy JDKs; full PQC today JCA provider Hybrid cert options OpenSSL/BoringSSL Cross-language interop/testing Validate handshakes & hybrids OpenSSL 3.5 offers X25519MLKEM768 as the default KeyShare for TLS. liboqs/wolfSSL Research/prototyping JNI bridges Algorithm exploration SPHINCS+/LMS/XMSS Firmware/long-term signatures Specialist libs HSM for state
69. Key & Certificate Management  Plan for larger key/cert sizes (buffers, DB fields, keystores)  Prefer PKCS#12 stores; validate parsing/limits  Track HSM/KMS PQC roadmaps; use software storage until supported  Rotate keys/certs; document hierarchies and signatures  Manage dual trust anchors during transition
70. Monitoring & Observability  Log negotiated cipher suites, key groups, cert validation results  Alerts for fallbacks, handshake errors, algorithm use beyond policy  Dashboards: PQC vs classical %, latency trends, error rates by algorithm  Tag requests for analysis (e.g., PQC-enabled)
71. Takeaways
72. Key Takeaways Quantum threats are real NIST PQC standards are ready Java already supports PQC Hybrid + crypto-agility Start now HNDL is active! • ML-KEM • ML-DSA • SLH-DSA Other standards are now being discussed. Hybrid key exchange support in TLS 1.3 (JEP 527) in JDK 27. (Sep 2026) For safe migration Migration spans years; monitor and iterate.
73. Call to Action  Weeks 1–2  inventory all crypto; identify long-lived data  Month 1  PoC with BC/JDK; measure performance  Months 2–3  roadmap; budget; stakeholder briefings  2026 Q3 – 2028  edge hybrid TLS; hybrid certificates; Java 27 (JEP 527)  2028+  migrate core apps; phase out classical; align to policy timelines
74. 22 crypto usage points are in a single Spring Boot service, but most of them are invisible. The tools are ready, and the standards are here. The only question is: “Will you start this week, or will you wait until it's too late?"
75. Vielen Dank! ありがとう! Thank you!