Java application security would be enhanced through two proposals aimed at resisting quantum computing attacks, one plan involving digital signatures and the other key encapsulation.

The two proposals reside in the OpenJDK JEP (JDK Enhancement Proposal) index. The Quantum-Resistant Module-Lattice-Based Digital Signature Algorithm proposal calls for enhancing the security of Java applications by providing an implementation of the quantum-resistant module-latticed-based digital signature algorithm (ML-DSA). ML-DSA would secure against future quantum computing attacks by using digital signatures to detect unauthorized modifications to data and to authenticate the identity of signatories. ML-DSA was standardized by the United States National Institute of Standards and Technology (NIST) in FIPS 204.

The Quantum-Resistant Module-Lattice-Based Key Encapsulation Mechanism proposal calls for enhancing application security by providing an implementation of the quantum-resistant module-lattice-based key encapsulation mechanism (ML-KEM). KEMs are used to secure symmetric keys over insecure communication channels using public key cryptography. ML-KEM is designed to be secure against future quantum computing attacks and was standardized by NIST in FIPS 203.

Both proposals warn of the threat posed to information security by advancements in the field of quantum computing. A future large-scale quantum computer could use Shor’s algorithm to compromise the security of widely deployed public-key-based algorithms. Such algorithms are used by the Java platform for activities such as digitally signing JAR (Java archive) files and establishing secure network connections. An attack could be accomplished by a quantum computer using Shor’s algorithm in hours. Cryptographers have responded to this threat by inventing quantum-resistant algorithms that cannot be defeated by Shor’s algorithm. Switching to quantum-resistant algorithms is urgent, even if large-scale quantum computers do not yet exist.

Each of the two proposals is eyed for the Standard Edition of Java, but neither is targeted for a specific version at this point. Both proposals were created August 26 and updated November 6.