Post-Quantum Cryptography Lands in Java LTS: A Migration Guide from Threat to Practice

Introduction: Cryptographic Transformation Under the Quantum Threat

With the rapid advancement of quantum computing, traditional public-key cryptographic systems face unprecedented security challenges. Encryption algorithms based on integer factorization (RSA) and elliptic curve discrete logarithm (ECC) will become vulnerable in the face of sufficiently powerful quantum computers. The root of this vulnerability lies in Shor's algorithm, proposed by mathematician Peter Shor in 1994—a quantum algorithm capable of performing integer factorization and discrete logarithm computation in polynomial time. On classical computers, factoring a 2048-bit RSA key would take an astronomically long time, but theoretically, a quantum computer with enough logical qubits could accomplish the same task in just hours. While current quantum computers (such as IBM's Heron processor and Google's Willow chip) don't yet have enough qubits or error-correction capabilities to threaten existing cryptographic systems, the industry generally estimates that Cryptographically Relevant Quantum Computers (CRQCs) could emerge in the mid-to-late 2030s. It's against this backdrop that integrating Post-Quantum Cryptography (PQC) into Java LTS (Long-Term Support) releases has become a focal point for the industry.

As one of the most widely used programming languages for enterprise applications, Java plays a critical role in finance, government, telecommunications, and other sectors with stringent security requirements. Integrating quantum-resistant cryptographic algorithms into Java LTS versions means that millions of production systems will be able to smoothly transition into the quantum-safe era.

Post-Quantum Cryptography Lands in Java LTS

What Is Post-Quantum Cryptography

The Real-World Threat from Quantum Computing

Post-quantum cryptography refers to cryptographic algorithms that can withstand attacks from quantum computers. At its core, it relies on mathematical problems that remain intractable even with quantum algorithms (such as Shor's algorithm)—for example, lattice-based problems, hash-based signatures, code-based problems, and multivariate equation systems.

Among these, lattice-based cryptography is one of the most important branches of post-quantum cryptography. Mathematically, a lattice refers to a discrete set of points in n-dimensional space formed by integer linear combinations of a set of basis vectors. The security of lattice cryptography primarily depends on two problems believed to remain hard under quantum computation: the Shortest Vector Problem (SVP—finding the shortest non-zero vector in a lattice) and the Learning With Errors problem (LWE—recovering a secret vector from a system of linear equations with noise). Module-LWE is a structured variant of LWE that significantly improves computational efficiency and reduces key sizes while maintaining security. It is the core construction used by ML-KEM and ML-DSA, which we'll discuss later. After more than two decades of cryptanalysis research, the hardness of lattice problems has earned strong recognition from the academic community.

The urgency of the quantum threat lies not only in the eventual maturation of quantum computers but also in the so-called "Harvest Now, Decrypt Later" (HNDL) attack model. Attackers can intercept and store encrypted data today, then decrypt it once quantum computing capabilities mature. Notably, HNDL is not a theoretical exercise—it has been confirmed as a real-world threat by intelligence agencies from multiple countries. According to public reports, some nation-state APT (Advanced Persistent Threat) groups are already systematically intercepting and storing encrypted communications. The U.S. National Security Agency (NSA) explicitly required national security systems to complete their migration to post-quantum cryptography by 2035 in its "Commercial National Security Algorithm Suite 2.0" released in 2022. The EU's ENISA, France's ANSSI, and Germany's BSI have issued similar migration timeline recommendations. For domains where data confidentiality requirements exceed 10–15 years—such as medical health records (HIPAA in the U.S. requires retention of 30+ years), intellectual property archives, and diplomatic communications—the HNDL threat means that data transmitted today could be decrypted by quantum computers within its confidentiality period. Therefore, migration to post-quantum cryptography must begin now.

The Driving Force of NIST Standardization

The U.S. National Institute of Standards and Technology (NIST) officially released its first batch of post-quantum cryptography standards in 2024, including:

ML-KEM (formerly CRYSTALS-Kyber): A lattice-based key encapsulation mechanism
ML-DSA (formerly CRYSTALS-Dilithium): A lattice-based digital signature algorithm
SLH-DSA (formerly SPHINCS+): A hash-based digital signature scheme

NIST's post-quantum cryptography standardization project began in 2016 and is one of the largest open solicitation and selection processes in the history of cryptography. The initial phase received 82 candidate submissions from 25 countries worldwide. After three rigorous rounds of review (covering security proofs, performance benchmarks, side-channel attack resistance, and many other dimensions), NIST announced the first selected schemes in 2022 and formally published three standards in August 2024: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA). Additionally, NIST is conducting a fourth round of evaluation, considering code-based schemes (such as HQC) as backup standards in case unexpected security vulnerabilities emerge in lattice-based cryptography. This diversified approach embodies the cryptographic security philosophy of "not putting all your eggs in one basket."

The establishment of these standards provides a clear technical direction for integrating post-quantum algorithms across programming languages and platforms.

Post-Quantum Cryptography Evolution on the Java Platform

Native Algorithm Implementation in the JDK

Post-quantum cryptography support in the Java ecosystem is being progressively advanced through the JDK's own cryptographic framework (JCA/JCE). The Java Cryptography Architecture (JCA) and Java Cryptography Extension (JCE) form the foundational cryptographic framework of the Java platform, employing the classic Service Provider Interface (SPI) design pattern. In this architecture, consumers of cryptographic algorithms (application developers) invoke cryptographic services through unified APIs (such as KeyGenerator, Cipher, Signature, etc.), while the actual algorithm implementations are provided by pluggable Providers. The JDK ships with several default Providers including SunJCE and SunEC. This decoupled design means that introducing new post-quantum algorithms can be done by registering a new Provider into the framework or extending existing Providers, while application-layer code only needs to change the algorithm name parameter to switch—for example, from KeyPairGenerator.getInstance("EC") to KeyPairGenerator.getInstance("ML-KEM").

The OpenJDK community has begun planning related JEPs (JDK Enhancement Proposals) aimed at integrating ML-KEM, ML-DSA, and other NIST standard algorithms as native implementations in the standard library.

This native integration is highly significant. Previously, developers who wanted to use post-quantum algorithms typically had to rely on third-party security libraries like Bouncy Castle. Bouncy Castle is an open-source cryptography library maintained by Australia's Legion of the Bouncy Castle Inc., and has long played a pioneering role in the Java cryptography ecosystem. Before native JDK support arrived, Bouncy Castle had been providing experimental implementations of NIST post-quantum candidate algorithms since version 1.72, including Kyber, Dilithium, SPHINCS+, Falcon, and others. Many enterprises that need to conduct early post-quantum migration validation (particularly financial institutions and government agencies) have been using Bouncy Castle for prototype development and compatibility testing.

While these third-party libraries are fully functional, incorporating algorithms directly into the JDK standard API means:

Better performance optimization (leveraging low-level JVM capabilities, including JIT compilation optimization and vectorized instructions like AVX-512/NEON for accelerated computation)
More standardized interface design (following the JCA Provider architecture)
Longer-term maintenance assurance (continuously updated alongside JDK releases)

Why the Focus on LTS Releases

Prioritizing the introduction of post-quantum cryptography in LTS releases is a pragmatic decision. Since Java 11, Oracle has established the current LTS release strategy, publishing a new LTS version every two years (Java 11, 17, 21, 25...), with each LTS version receiving at least 8 years of extended support. In contrast, non-LTS versions (such as Java 22, 23, 24) have only a 6-month support window. According to statistics from Eclipse Adoptium and New Relic, over 80% of production Java applications run on LTS versions. LTS versions (such as Java 21 and the upcoming Java 25) offer multi-year official support cycles and are the preferred choice for the vast majority of enterprise production environments. Providing stable post-quantum cryptography support in these versions ensures that enterprise users can gain quantum-threat resistance without frequent major version upgrades.

Notably, migrating security features to LTS versions typically requires careful backporting work—introducing new capabilities while ensuring no disruption to the compatibility and stability of existing systems. Backporting security features to LTS versions is a complex engineering task: it requires introducing new algorithm implementations without changing public API signatures, handling compatibility with the existing SecurityManager and module system (JPMS), and passing TCK (Technology Compatibility Kit) compliance tests. The OpenJDK community's "Updates" project specifically coordinates this kind of porting work, ensuring that security patches and critical features can reach the LTS user base in a timely manner.

Migration Practices and Technical Challenges

Hybrid Cryptographic Schemes: A Gradual Transition Strategy

In practical deployments, the industry widely recommends adopting a "Hybrid Mode" as a transitional approach—simultaneously using both traditional and post-quantum algorithms. This way, even if one algorithm is broken, the other still provides protection. This conservative strategy has already been widely adopted in the post-quantum migration of the TLS protocol.

Specifically, Google Chrome has experimentally deployed the X25519Kyber768 hybrid key exchange in TLS 1.3 since 2023 (later updated to X25519MLKEM768), combining the traditional X25519 elliptic curve Diffie-Hellman key exchange with ML-KEM-768 post-quantum key encapsulation. Cloudflare and Amazon AWS have also enabled similar hybrid schemes in their CDN and load balancing services. The specific implementation of hybrid schemes involves combining the shared key material generated by both algorithms through a Key Derivation Function (KDF), ensuring that the final session key depends on the security of both algorithms. This "seatbelt plus airbag" dual-protection strategy is expected to remain the industry standard practice throughout a considerable transition period.

For Java applications, this means introducing dual protection at the key exchange and digital signature stages, while JSSE (Java Secure Socket Extension) also needs corresponding updates to support hybrid TLS handshakes. Although this introduces some performance overhead and increased data volume (post-quantum algorithm keys and signatures are typically much larger than those of traditional algorithms), it's a worthwhile trade-off in the name of security.

Performance and Compatibility Considerations

Post-quantum algorithms differ significantly from traditional algorithms in terms of computational overhead and data size:

Comparison Dimension	Traditional ECC	ML-KEM (Post-Quantum)
Public Key Size	~32–64 bytes	~800–1568 bytes
Ciphertext/Signature Size	Smaller	Significantly larger
Computational Overhead	Lower	Moderate to high

This introduces new requirements for network transmission, storage, and memory usage. Java developers need to reassess resource planning for related systems during migration, especially in high-concurrency scenarios. Particular attention should be paid to the increased latency during TLS handshakes—due to larger key sizes, the network data transmitted per handshake may increase several-fold, with the impact being especially pronounced in bandwidth-constrained scenarios such as mobile networks and IoT.

Conclusion: Preparing for the Quantum Era

Introducing post-quantum cryptography into Java LTS releases is a critical strategic move for the Java platform's future security. Although practical quantum computers have not yet arrived, cryptographic migration is a long-cycle, wide-reaching systems engineering effort—the earlier it begins, the more manageable it becomes.

For Java developers and enterprise architects, now is the time to understand NIST post-quantum standards, assess existing system cryptographic dependencies, and develop migration roadmaps. Recommended action steps include: conducting a cryptographic algorithm inventory (Crypto Inventory) of existing codebases to identify all hardcoded algorithm references; using third-party libraries like Bouncy Castle to set up test environments and validate post-quantum algorithm performance in business scenarios; and following the progress of related JEPs in the OpenJDK community to prepare for a smooth transition when native JDK support arrives. When JDK native support gradually matures, organizations that have prepared in advance will hold the initiative in the quantum-safe era.