Java app security would get a boost through quantum resistance

Java application security would be enhanced through a couple of proposals to resist 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. One proposal, titled “Quantum-Resistant Module-Lattice-Based Digital Signature Algorithm,” calls for enhancing the security of Java applications by providing an implementation of the quantum-resistant Module-Latticed-Based Digital Signature Algorithm (ML-DSA). Digital signatures are used to detect unauthorized modifications to data and to authenticate the identity of signatories. ML-DSA is designed to be secure against future quantum computing attacks. It has been standardized by the United States National Institute of Standards and Technology (NIST) in FIPS 204.

The other proposal, “Quantum-Resistant Module-Lattice-Based Key Encapsulation Mechanism,” 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 has been standardized by NIST in FIPS 203.

Both proposals emphasize growing advancement 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 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.