What should Java developers prepare for the Post-Quantum Era?

Devoxx Morocco 2025

Transcript

1. What should Java developers prepare for the Post-Quantum Era? NISHIKAWA, Akihiro (Aki) Cloud Solution Architect, Microsoft @logico_jp @logico-jp.dev linkedin.com/in/anishi1222/
2. َلَع ُماَلَّسلَا ْمُكْي こんにちは! Hello! { "name": "Akihiro Nishikawa", "country": "Japan", "workFor": "Microsoft", "favourites": [ "JVM", "GraalVM", "Azure" ], "expertise": [ "Application integration", "Container", "Serverless" ] }
3. Agenda  Problem & Urgency  PQC support in Java  TLS Migration Strategy  Takeaways & Call to Action
4. TL;DR  Quantum Threat is Real  Quantum computers can break current public-key cryptography (RSA, ECC), enabling "Harvest now, Decrypt later" attacks on long-term confidential data.  PQC is the Solution  Post-Quantum Cryptography (PQC) algorithms are emerging as quantum-resistant solutions.  Java is Adapting  Has natively supported ML-KEM and ML-DSA since Java 24.  However, it has not supported JSSE/TLS yet.  Sooner action  Can avoid last-minute panic.  Crypto-agility  Helps you make migration easy and crypto pluggable.
5. Problem & Urgency
6. Will your Java apps be secure in ten years' time?
7. Your data may be already compromised...  If 10-year retention is mandated, ... 2035 End of retention period 2025 Data encrypted with RSA/ECDSA
8. Harvest-Now, Decrypt-Later (HNDL) Attacks Adversaries have captured encrypted data to decrypt it when quantum computers emerge. 2030+ Quantum computer emerges 2035 End of retention period HNDL attack 2025 Data encrypted with RSA/ECDSA
9. Q-Day The moment quantum computers can break today’s public-key cryptography. Q-Day.org - Q-Day, Y2Q, PQC, Quantum Readiness, Quantum Security 2030+ Quantum computer emerges 2035 Q-Day End of retention period HNDL attack 2025 Data encrypted with RSA/ECDSA
10. If Q-Day happens sooner... 2030+ Quantum computer emerges 2035 End of retention period Q-Day HNDL attack 2025 Data encrypted with RSA/ECDSA
11. 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  lattice problems  hash-based structures  error-correcting codes, etc.  No quantum hardware is needed.  These algorithms run on classical computers.
12. NIST Standards National Institute of Standards and Technology  Post-Quantum Cryptography | CSRC  ML-KEM (FIPS 203)  Module Lattice based Key Encapsulation Mechanism  Key establishment, based on CRYSTALS-Kyber  ML-DSA (FIPS 204)  Module Lattice based Digital Signature Algorithm  For digital signatures, based on CRYSTALS-Dilithium  SLH-DSA (FIPS 205)  StateLess Hash-based Digital Signature Algorithm  for stateless hash-based signatures (SPHINCS+)
13. More standards will be selected and added Post-Quantum Cryptography | CSRC  HQC (Hamming Quasi-Cyclic)  a backup for ML-KEM  NIST Selects HQC as Fifth Algorithm for Post-Quantum Encryption | NIST  AMS :: Feature Column from the AMS  Now evaluating FALCON (“FN-DSA”)  a second general-purpose signature algorithm  Quantum-Ready FN-DSA (FIPS 206) Nears Draft Approval from NIST | DigiCert  CSRC Presentations | CSRC
14. Why are sooner actions needed?
15. The Quantum Computer Breakthrough Required Qubits 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 Reestimated 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
16. There’s a Big Gap Between Awareness and Action. 65% 69% 5% ~65% of organisations are concerned about HNDL attacks 2025_07_10_Capgemini_Post-Quantum-Cryptography- Report_News-Alert.pdf 69% of organisations believe quantum computing will break encryption within 5 years Quantum Readiness Gap: A DigiCert Study On Quantum- Safe Encryption yet only ~5% have started implementing PQC solutions. Just 5% of Enterprises Have Deployed Quantum-Safe Encryption - Infosecurity Magazine
17. Government Deadlines Are Real US National Security Agency [NSA] 2027 2030 2035 2028 2029 2031 2032 2033 2034 2027 2030 2035 2028 2029 2031 2032 2033 2034 By December 31, 2030 all equipment and services that cannot support CNSA 2.0 must be phased out unless otherwise noted. By January 1, 2027 all new acquisitions for NSS will be required to be CNSA 2.0 compliant unless otherwise noted. Complete migration for all national security systems by 2035. By December 31, 2031 CNSA 2.0 algorithms are mandated for use unless otherwise noted.
18. Global Roadmap Comparison US 2027 – New procurement must incorporate PQC 2030 – Deadline for phasing out non-PQC-compliant equipment 2035 – Full transition of national security systems NSA's CNSA 2.0 Guidance (National Security Memorandum NSM-10) • NSA's CNSA 2.0 Guidelines (NSM 10) • $7.1 billion budget estimate EU 2030 – Completion of PQC migration in government agencies and critical infrastructure 2035 – Full transition (where feasible) • European Commission Recommendation (April 2024) • EU Roadmap (June 2025) • Cross-Member State research budget (e.g.; Horizon Europe) UK ~2034 – Full transition target (estimated) • Timelines for migration to post-quantum cryptography (March 2025) JP 2030s – Target for completion of transition (provisional) • Ministry of Internal Affairs and Communications Report (2021) AU By 2030 – Ensure quantum resistance for confidential data • Australian Signals Directorate (ASD) Recommendation (2022)
19. And...  Cryptographic infrastructure transitions are multi-year endeavours fraught with compatibility issues (e.g., historical migrations from SHA-1 to SHA-256, TLS 1.2 to 1.3).  [2408.05997v4] On the Formalization of Cryptographic Migration  Cryptographic migration takes a long time ... For example, it took many organisations 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. – The PQC Migration Handbook
20. Industry Movement Amazon Web Services ML-KEM post-quantum TLS now supported in AWS KMS, ACM, and Secrets Manager Amazon CloudFront launches TLS security policy with post-quantum support AWS Private CA now supports post-quantum digital certificates Google Cloud Announcing quantum-safe digital signatures in Cloud KMS Microsoft Azure Quantum-safe security: Progress towards next-generation cryptography Cloudflare X25519+ML-KEM-768 hybrid key exchange in production (opt-in) Cloudflare Radar Akamai Post-Quantum Cryptography Implementation Considerations in TLS [Note] • Other major providers (IBM, Alibaba, etc.) are also experimenting with PQC in their offerings.
21. Real-world uptake of PQC is faster than expected  Major browsers now default to hybrid post-quantum TLS.  By late 2025, all leading browsers and TLS libraries have X25519+Kyber-768 enabled by default.  Chrome 131+/Firefox 132+/Safari 26+  Over 50% of Cloudflare’s traffic uses PQC encryption.  State of the post-quantum Internet in 2025
22. Why Are Java Applications at Risk? Applications for businesses last a long time. Typical Java/Web usage usually involves cryptography. Vulnerability Critical insight
23. Business & Security Risks Security Risk Business Risk Cost & Effort Late Adoption Woes
24. PQC support in Java
25. Future JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3 Java PQC Timeline A timeline of Java (JDK) releases and their post-quantum crypto features: JEP 452: KEM (Key Encapsulation Mechanism) API – groundwork for KEMs JEP 496: ML-KEM (Kyber-based KEM) JEP 497: ML-DSA (Dilithium-based signatures) JEP 510: Extended KDF API (Key Derivation Functions) for hybrid protocols # No PQC algorithms included (APIs only) # Default JSSE does not cover PQC in TLS yet. Java 21 Sep 2023 Java 24 Mar 2025 Java 25 Sep 2025 # Default JSSE will cover these algorithms in TLS.
26. 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 to 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);
27. 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);
28. Bouncy Castle https://www.bouncycastle.org/  Comprehensive PQC support ahead of the JDK.  BC 1.79 and 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()); .// KeyPairGenerator kpg = KeyPairGenerator.getInstance("ML-DSA", "BC");
29. Current Limitations & Gaps • JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3 (will be introduced after RFC is issued.) • The more algorithms NIST standardizes, the more will be added to future Java versions. • Current default JSSE doesn’t cover PQC in TLS (but we can customize JSSE). Java Secure Socket Extension (JSSE) Reference Guide • ML-KEM and ML-DSA are available in JDK 24/25 APIs.
30. Migration Strategy
31. Migration Strategy Hybrid Phased Crypto- agility Timeline
32. 1. Hybrid Combine traditional cryptography with PQC to make security better. Pros Cons Classic Long security verification history. Vulnerability to quantum computers is a concern. PQC No efficient solution using quantum computers. Short security verification history. (a risk to be broken) ECDHE-MLKEM in TLS 1.3 is already implemented on browsers, CDN, TLS libraries. - Chrome 131+/Firefox 132+/Safari 26+ draft-ietf-tls-ecdhe-mlkem-01 - Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3 draft-ietf-tls-hybrid-design-16 - Hybrid key exchange in TLS 1.3 JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3
33. PKI Certificate Migration EJBCA 9.1 supports ML-KEM/ML-DSA certificate issuance. (Enterprise JavaBeans Certificate Authority)  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-13 - Composite ML-DSA for use in X.509 Public Key Infrastructure EJBCA - The Open-Source Certificate Authority (CA)
34. Key Exchange flow in TLS 1.3 (as of now) Generate (EC)DHE key pair Send ClientHello ClientHello - key_share (includes PK_c) - signature algorithms - psk_key_exchange_modes - pre_shared_key 1. Decide key algorithm 2. Generate (EC)DHE keypair Derive shared_secret with (EC)DHE Derive handshake_secret from shared_secret by HKDF shared_secret =ECDH(PK_c, SK_s) handkshake_secret =HKDF(shared_secret ...) Send ServerHello Derive shared_secret with (EC)DHE Derive handshake_secret from shared_secret by HKDF shared_secret =ECDH(PK_s, SK_c) handkshake_secret =HKDF(shared_secret ...) Decrypt encrypted parts of ServerHello with a key derived by HKDF from handshake_secret Public key (PK_c) Private key (SK_c) Public key (PK_s) Private key (SK_s) ServerHello - key_share (includes PK_s) - pre_shared_key - EncryptedExtensions - CertificateRequest - Certificate - CertificateVerify - Finished - Application Data Encrypted with a key derived by HKDF from handshake_secret.
35. Hybrid Key Exchange flow in TLS 1.3 with ECDHE and ML-KEM draft-ietf-tls-hybrid-design-16 - Hybrid key exchange in TLS 1.3 Generate (EC)DHE key pair Send ClientHello 1. Decide key algorithm 2. Generate (EC)DHE keypair Derive shared_secret_x with (EC)DHE Derive handshake_secret from shared_secret by HKDF shared_secret_x =ECDH(PK_c, SK_s) handkshake_secret =HKDF(shared_secret ...) Public key (PK_c) Private key (SK_c) Public key (PK_s) Private key (SK_s) Generate (PQ)KEM key pair Encapsulation key (EK) Decapsulation key (DK) 1. Generate shared_secret_y 2. Encapsulate the secret with EK Enc=Encap(EK, shared_secret_y) Concatenate shared_secret=shared_secret_x || shared_secret_y ClientHello - key_share (includes PK_c, EK) - signature algorithms - psk_key_exchange_modes - pre_shared_key [Note] In the key_share extension of ClientHello, a new public key and the encapsulation key (EK) are sent at the same time. The server performs 1. ECDH key exchange to derive shared_secret_x 2. Encapsulates the randomly generated key shared_secret_y 3. Combines shared_secret_x and shared_secret_y to derive shared_secret 4. Generates handshake_secret using the HMAC Key Derivation Function (HKDF).
36. Send ServerHello Derive shared_secret_x with (EC)DHE Derive handshake_secret from shared_secret by HKDF shared_secret_x =ECDH(PK_s, SK_c) handkshake_secret =HKDF(shared_secret ...) Decrypt encrypted parts of ServerHello with a key derived by HKDF from handshake_secret Decapsulate enc with EK and obtain shared_secret_y shared_secret_y =Decap(DK, Enc) Concatenate shared_secret=shared_secret_x || shared_secret_y ServerHello - key_share (includes PK_s, Enc) - pre_shared_key - EncryptedExtensions - CertificateRequest - Certificate - CertificateVerify - Finished - Application Data [Note] In the key_share extension of ServerHello, a new public key and the shared_secret_y are sent at the same time. The steps in the client are similar to what the Server performs. That is, 1. Performs an ECDH key exchange to derive shared_secret_x 2. Decapsulates to derive shared_secret_y 3. Combines shared_secret_x and shared_secret_y to derive shared_secret, 4. Generates handshake_secret using the HKDF. Encrypted with a key derived by HKDF from handshake_secret.
37. Performance impact  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 ML-KEM-768 Public key shared key for encapsulation X25519 public key Key size (byte) 1184 1088 32
38. 2. Phased Gradually extend hybrid TLS 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 supports JEP 527 Phase 3: end-to-end PQC; retire classical ciphers where feasible Backends Java app CDN/Proxy Client
39. Phase-1 Start by using Hybrid TLS at the Edge. Client Hybrid TLS Classic TLS CDN/Proxy Java app Backends Classic TLS
40. Phase-2 Communication between CDN and Java app uses Hybrid TLS. Client Hybrid TLS Classic TLS CDN/Proxy Java app Backends Hybrid TLS
41. Phase-3 All communications are using Hybrid TLS and PQC is used by default. Client Hybrid TLS Hybrid TLS CDN/Proxy Java app Backends Hybrid TLS
42. Phase-4 After a while, not hybrid but PQC TLS will be used in all communication. Client PQC TLS (not hybrid) PQC TLS (not hybrid) CDN/Proxy Java app Backends PQC TLS (not hybrid)
43. 3. Crypto-Agility Design Principles  Don’t hard-code algorithm names or parameters  Externalize choices in configuration  Abstract crypto behind interfaces (strategy pattern)  Leverage JCA providers; enable provider swapping  Prepare fallback toggles and feature flags
44. // Config (YAML) signature: algorithmType: ML-DSA # switchable: RSA, ML-DSA, etc. Env variables are also fine. keySize: 2048 # if applicable // Java (Strategy + DI) public interface SignService { byte[] sign(byte[] data, PrivateKey key) throws Exception; boolean verify(byte[] data, byte[] sig, PublicKey key) throws Exception; } @Service public class RSASignService implements SignService { // .// */ } @Service public class MLDSASignService implements SignService { // .// */ } @Configuration public class CryptoConfig { @Value("${signature.algorithmType}") private String algType; @Bean public SignService signService(Optional<RSASignService> rsa, Optional<MLDSASignService> mlDsa) { return "ML-DSA".equalsIgnoreCase(algType) ? mlDsa.orElseThrow() : rsa.orElseThrow(); } }
45. 4. Migration Timeline 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
46. Performance & Operational Impact Metric Impact Mitigation Key / signature sizes[1] Larger (KBs vs bytes) Resize buffers; optimise certificate chains TLS handshake latency Small % increase TLS 1.3; session resumption; avoid extra RTT CPU usage Moderate increase Modern JVM/CPUs; profile; selective PQC use Network bandwidth Larger ClientHello/Cert messages Certificate compression; conditional key-share HSM support Varies by vendor Track roadmaps; software keys until supported RSA-2048 ECDSA(P-256) ML-KEM-768 ML-DSA-65 SPHINCS+ Key Size 256 B 32 B pubkey ~1,184 B ~1,312 B varies Signature Size 256 B 64 B N/A (KEM) ~2,420 B 8–17 KB [1] Key and signature size
47. Common Migration Challenges Issue Impact Solution Protocol ossification Handshake failures Canary rollout; fallback; GREASE (RFC 8701) https://www.rfc-editor.org/rfc/rfc8701 Legacy client compatibility Breakages Hybrid TLS/certs; staged enablement Certificate size bloat Latency/storage Trim chains; compression; monitor limits Library updates Security gaps Frequent upgrades; track advisories Stateful signatures State loss risks HSM/state management; procedures Side-channel leakages Leakage risks Constant-time libs; cross-HW testing
48. Best Practices 1. Inventory all cryptographic uses (TLS, signing, storage, tokens) 2. Design for crypto-agility (config + abstractions) 3. Prefer hybrid modes during transition 4. Test thoroughly (vectors, interop, performance, fallback) 5. Monitor and alert on crypto behaviours 6. Manage side-channel risks 7. Stay informed (NIST/IETF/JEPs; library releases)
49. Step 1 – Crypto Asset 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
50. Step 2 – Testing Strategy Unit official vectors for ML-KEM/ML-DSA Integration cross-implementation (Java <-> OpenSSL/liboqs) hybrid TLS handshakes 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
51. Step 3 – Library Selection & Management Library/Tool Use Case Notes JDK 25+ Built-in PQC APIs Prefer standards TLS hybrid pending Bouncy Castle Legacy JDKs; full PQC today JCA provider Hybrid cert options OpenSSL/BoringSSL Cross-language interop/testing Validate handshakes & hybrids liboqs/wolfSSL Research/prototyping JNI bridges Algorithm exploration SPHINCS+/LMS/XMSS Firmware/long-term signatures Specialist libs HSM for state
52. Step 4 – 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
53. Step 5 – 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)
54. Common Pitfalls to Avoid Mistake Better Approach Hard-coding algorithm names Configuration + DI for flexibility Ignoring backward compat. Hybrid mode and staged rollout No rollback plan Design graceful fallbacks Only “happy path” testing Include error cases, versions, unsupported groups Waiting for perfection Start PoCs now; iterate Ignoring performance Measure early; optimize handshake/key usage Side-channels overlooked Use constant-time libs; run side-channel tests Vendor lock-in Open standards; multiple providers 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. Takeaways
56. Key Takeaways Quantum threats are real NIST PQC standards are ready Java already supports PQC APIs 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) expected in upcoming JDK. For safe migration Migration spans years; monitor and iterate.
57. 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–2027  edge hybrid TLS; hybrid certificates; prep for JEP 527 introduced JDK  2027+  migrate core apps; phase out classical; align to policy timelines
58. The investment made today is an essential insurance policy to guarantee the reliability of systems and data for decades to come.
59. Appendix
60. Resources (1/3)  Q-Day.org - Q-Day, Y2Q, PQC, Quantum Readiness, Quantum Security  Post-Quantum Cryptography | CSRC  National Institute of Standards and Technology  NIST Selects HQC as Fifth Algorithm for Post-Quantum Encryption | NIST  Quantum-Ready FN-DSA (FIPS 206) Nears Draft Approval from NIST | DigiCert  CSRC Presentations | CSRC  How to factor 2048 bit RSA integers in 8 hours using 20 million noisy qubits – Quantum  [2505.15917] How to factor 2048 bit RSA integers with less than a million noisy qubits  2025_07_10_Capgemini_Post-Quantum-Cryptography-Report_News-Alert.pdf  Quantum Readiness Gap: A DigiCert Study On Quantum-Safe Encryption  Just 5% of Enterprises Have Deployed Quantum-Safe Encryption - Infosecurity Magazine  National Security Memorandum on Promoting United States Leadership in Quantum Computing While Mitigating Risks to Vulnerable Cryptographic Systems | The White House  White House to require post-quantum encryption plans from agencies  Recommendation on a Coordinated Implementation Roadmap for the transition to Post-Quantum Cryptography | Shaping Europe’s digital future  NCSC - NCSC.GOV.UK
61. Resources (2/3)  Planning for post-quantum cryptography | Cyber.gov.au  [2408.05997v4] On the Formalization of Cryptographic Migration  The PQC Migration Handbook - Guidelines for migrating to Post-Quantum Cryptography  ML-KEM post-quantum TLS now supported in AWS KMS, ACM, and Secrets Manager | AWS Security Blog  Amazon CloudFront launches TLS security policy with post-quantum support – AWS  Announcing quantum-safe digital signatures in Cloud KMS | Google Cloud Blog  AWS Private CA now supports post-quantum digital certificates - AWS  Quantum-safe security: Progress towards next-generation cryptography | Microsoft Security Blog  Cloudflare Radar  Post-Quantum Cryptography Implementation Considerations in TLS | Akamai  State of the post-quantum Internet in 2025  JEP 452: Key Encapsulation Mechanism API  JEP 496: Quantum-Resistant Module-Lattice-Based Key Encapsulation Mechanism  JEP 497: Quantum-Resistant Module-Lattice-Based Digital Signature Algorithm  JEP 510: Key Derivation Function API  JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3  Java Secure Socket Extension (JSSE) Reference Guide
62. Resources (3/3)  Bouncy Castle open-source cryptographic APIs  draft-ietf-tls-ecdhe-mlkem-01 - Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3  draft-ietf-tls-hybrid-design-16 - Hybrid key exchange in TLS 1.3  draft-ietf-lamps-pq-composite-sigs-13 - Composite ML-DSA for use in X.509 Public Key Infrastructure  EJBCA - The Open-Source Certificate Authority (CA)  OpenSSL  boringssl - Git at Google  liboqs | Open Quantum Safe  wolfSSL Embedded SSL/TLS Library – wolfSSL  SPHINCS+  SP 800-208, Recommendation for Stateful Hash-Based Signature Schemes | CSRC  RFC 8554: Leighton-Micali Hash-Based Signatures  RFC 8391: XMSS: eXtended Merkle Signature Scheme
63. اليزج اركش! ありがとう! Thank you!