POST-QUANTUM CRYPTOGRAPHY IN THE JAVA ECOSYSTEM

Abstract

The completion of NIST standardization in 2024, with the publication of ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205), has confronted Java developers with a concrete practical question: how to integrate these algorithms into real-world applications using the available platform tools. The Java ecosystem offers several fundamentally different integration paths depending on the JDK version; however, a systematic description of these approaches from a practitioner’s perspective remains insufficiently represented in the scientific literature. This paper analyzes the evolution of post-quantum cryptography support in the Java platform from JDK 17 through JDK 25, with an outlook toward JDK 27. The Java Cryptography Architecture and the role of the provider model as a foundation for implementing the crypto agility concept are examined. Two API levels of the BouncyCastle 1.83 library – the JCA provider and the low-level lightweight API – are compared, and the appropriate use cases for each are identified. It is established that native support in JDK 25 covers only ML-KEM and ML-DSA, while SLH-DSA remains available exclusively through BouncyCastle across all JDK versions, demonstrating the asynchronous nature of NIST standardization and JDK platform integration. Practical code examples are developed and analyzed for two typical scenarios. The first involves hybrid JWT token signing using both classical ECDSA and post-quantum ML-DSA simultaneously in a Spring Boot application, ensuring backward compatibility with existing infrastructure. The second addresses secure inter-service communication via ML-KEM with public key authentication using ML-DSA to protect against man-in-the-middle attacks. It is shown that direct use of ML-DSA in JWT is incompatible with existing libraries due to the absence of corresponding algorithms in RFC 7515 and RFC 7518, and practical mitigation approaches for the transition period are proposed, including reference tokens and token introspection. A four-phase migration strategy for enterprise Java systems is proposed: inventory of cryptographic dependencies, introduction of crypto agility through centralized algorithm configuration in Spring Boot, a hybrid mode of parallel classical and post-quantum algorithm usage, and full migration following PQC TLS standardization in JDK 27. The results of this work can be directly applied by Java developers when planning and implementing the migration of enterprise applications to postquantum cryptographic standards