Quantum computers are expected to perform calculations exponentially faster than traditional computers. Quantum computing promises to enable us to tackle more complex problems and has the potential to dramatically impact our approach with Artificial Intelligence.

However, one of the undesirable impacts of quantum computing is the decline of certain cryptographic algorithms. Since quantum computers will perform complex calculations more quickly than classical computers, they will be able to break crypto mechanisms that are considered safe today.

While the industry may not agree when quantum computers will become practical and available to malicious actors, it does agree with the need to deprecate traditional cryptographic schemes. The challenge is to come up with cryptographic infrastructure capable of operating on traditional computers and resistant to attacks from both traditional and quantum computers.

This challenge is typically called “post quantum cryptography” (PQC).

Many mainstream cryptographic mechanisms, including those using asymmetric cryptography such as RSA, ECDH, and ECDSA can be weakened or fully broken by quantum computers. All use cases for cryptographic functions, including the mechanisms for performing encryption at rest and in transit, and ensuring authenticity, will be affected.

General challenges for adopting post-quantum cryptography

Several general challenges are associated with enabling post-quantum cryptography in existing applications:

  • The need to use standards that are approved by regulators and industry groups. For example, the Federal Information Processing Standards (FIPS) have been updated to deal with post-quantum cryptography.
  • The need to ensure continued interoperability of systems making use of the updated cryptographic mechanisms (hence the importance of standards as well as selection of PQC security parameters and algorithms).
  • The need to provide customers with easy-to-adopt PQC solutions while aiming to reduce the chances of introducing stability or performance issues.  These solutions should meet a wide range of customers’ organizational, geographical, and regulatory requirements.
  • The need to deliver products or libraries with new Application Programming Interfaces (APIs) meeting requirements for both classical cryptography and post quantum cryptography (for example, key encapsulating APIs) to help with interoperability with legacy applications.

Quantum computer resistant cryptography

For data-at-rest encryption, the prevailing view is that quantum attacks reduce the strength of traditional cryptography. Symmetric key sizes and hash output lengths must be doubled to achieve the same level of protection against quantum computers.  

It’s tempting to assume that simply doubling symmetric key sizes is enough, since that’s a smaller change than adopting a new algorithm. But this only works if you can keep data encryption keys confidential. Those keys are typically wrapped by a master key managed in a key management service that uses Hardware Security Modules (HSMs). If that service is remote, the communication channel must be secured to prevent exposure of data encryption keys in transit. In practice, then, protecting data at rest from quantum threats hinges on protecting data in transit as well. Accordingly, keys should be exchanged using quantum-safe protocols, such as TLS 1.3 with PQC cipher suites.

Cryptography and secure networked communications

For secure networked communications, consider the difference between active and passive quantum computer attacks.

An active attack is a real-time man in the middle scenario where an adversary with a quantum computer intercepts communications directly. Because this isn’t yet practical, current PKI – using ECDSA and RSA certificates for server authentication – remains acceptable for now, though some key-establishment adjustments are still needed as discussed below. By contrast, passive threats demand immediate action: in “harvest now and decrypt later” attacks, adversaries capture encrypted data today to decrypt once quantum capabilities advance.

The “harvest now and decrypt later” scenario

Security professionals are increasingly worried about the “harvest now and decrypt later” scenario.  

It is generally accepted that malicious actors, particularly state actors with large computing resources available, are collecting (“harvesting”) large amounts of encrypted data (either through interception of encrypted data in-transit or exfiltration of encrypted data at rest upon a successful system compromise), with the intent to leverage quantum computers to decrypt this data at a later time. This concern is leading the push to adopt PQC strategies now, even though quantum computers are not currently believed to be capable of practical attacks.

To protect at-rest data against “harvest now and decrypt later” attacks, the highest priority is to properly configure systems to prevent the exfiltration of encrypted data in the first place. This requires tightening systems access, ensuring limited privileges, timely applications of security updates, etc. Encryption is the second line of defense as it is intended to prevent the interpretation of the data should the data in its encrypted form be exfiltrated upon successful compromise. As discussed previously (see “Quantum computer resistant cryptography”), organizations can consider doubling the key sizes used in symmetric encryption to maintain the same level of protection in a post-quantum era.  However, this assumes that keys are properly secured and were not stolen when the system was compromised.

To protect data in transit against the “harvest now and decrypt later” attacks (i.e., passive network attacks), the simplest solution is to make the key exchange mechanism in communication protocols quantum safe while retaining classic handshake signatures and current Public Key Infrastructure (PKI).

What about long-lived document signing?

Cryptographic functions are routinely used to help ensure the authenticity and integrity of certain documents, including long-lived documents. Examples of long-lived documents include firmware and electronically signed documents such as legal agreements.

There is a need to adopt mechanisms that will continue to certify the validity of these documents over long periods of time (measured in years for legal documents).  Consider also that signed firmware enables other important security mechanisms to protect against complex hardware-based attacks. For example, mechanisms such as secure boot through Unified Extensible Firmware Interface rely on cryptographic functions to validate firmware.

Therefore, even as cryptographic mechanisms evolve to resist quantum-based attacks, it remains essential to preserve verification methods that ensure long-lived documents can still be validated on legacy systems.

Highlights of Oracle’s PQC strategy

Reflecting on the many challenges highlighted in this blog, Oracle is pursuing a transitional strategy to prepare for the post quantum era, while maintaining existing technical capabilities and preventing compatibility issues with classical encryption mechanisms in customers’ products and cloud services.

To protect against passive attacks, Oracle’s cryptography and development teams are working as follows:

  • Cryptography providers: Oracle’s cryptography teams are implementing the latest FIPS approved algorithms in cryptography providers, beginning with the  FIPS 203 ML-KEM key encapsulation algorithm and the FIPS 204 ML-DSA signature algorithm. This represents the first step in adding quantum-safe capabilities to the cryptographic protocols used across Oracle products and cloud services.
  • Hybrid key establishment: Oracle is implementing hybrid key establishments for most environments. This approach combines classical and quantum-safe mechanisms to generate shared secrets across protocols such as TLS 1.3, SSH, and IKE v2. The hybrid model integrates seamlessly with existing protocols, without requiring changes in Public Key Infrastructure or issuing new certificates. This approach also requires minimal protocol adjustments in current IETF RFCs. However, Oracle may also support other approaches as specific US regulated systems under the Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) may require non-hybrid solutions.
  • Foundational technologies: Oracle is developing PQC solutions in core technologies such as Java and Oracle Database that are easy for customers to adopt and that minimize risks to stability and performance.

With these objectives in mind, Oracle’s current PQC approach can be summarized as follows:

  • Data at rest encryption is shifting to AES 256
  • Data in transit encryption is shifting to leverage hybrid key-exchange.
  • Oracle is implementing FIPS 204 ML-DSA signatures without PKI changes, by directly trusting public keys. This is applicable to various long term or ephemeral schemes.
  • Over time, as PQC algorithms are being implemented and more widely accepted across the industry, Oracle expects to introduce PQC-only certificates, beginning with trust chains anchored in private CA PQC roots. These PQC certificates will complement existing certificates (e.g., ECDSA certs) to address active quantum computing threats.
  • Regarding firmware and long-lived documents signing:
    • During its transition period, Oracle plans to use both classical and PQC signatures side-by-side. This will enable organizations to gradually phase out older mechanisms to adopt quantum-resistant mechanisms. Oracle’s objective with firmware signing is to align with existing government and industry requirements including the Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) requirements by incorporating stateless signatures or stateful hash-based digital signatures in hardware security modules reflecting the intended security assurance level of these systems. 
    • Oracle will leverage the fact that signature validation does not always require a full Public Key Infrastructure (PKI). In some cases, trust in the public key can be established directly without a third-party authority for example, when Oracle controls the root of trust in operating systems like Oracle Linux.

Below are several examples of PQC transition changes that have been made for key Oracle components.

Oracle Database

Refer to https://blogs.oracle.com/database/oracle-ai-database-26ai-pqc

Java

Oracle is continuing to make progress and collect feedback to bring PQC enhancements to the Java Development Kit (JDK) through the Java Enhancement Process (“JEP”).

As a result, Oracle made enhancements to the Java Cryptography Extension (JCE):

Additionally, new algorithms have already been implemented or are planned in existing Java roadmaps, for example:

Oracle has started the development of PQC TLS mechanisms for Java combining post-quantum and traditional algorithms which will be released in future versions. 

Additionally, Oracle intends in future Java versions:

  • To backport updated TLS mechanisms and PQC support to long term support releases, in a similar way to how Oracle backported TLS 1.3 implementation in 2018 for Java SE 8 (which was initially released in 2014). These backports will be driven by customer demand to enable as much as possible PQC in existing Java applications.

Oracle and OpenSSL

Oracle makes regular contributions to OpenSSL. Oracle’s PQC contributions to OpenSSL 3.5 are being integrated into Oracle Jipher and into Oracle Linux.

Oracle Jipher is a Java Cryptographic Service Provider that packages a FIPS 140 validated OpenSSL cryptographic module. Java applications can use it to deliver enterprise class solutions into regulated environments.

Oracle Linux, which powers Oracle Cloud and Oracle Exadata, provides OpenSSL as a core system library used by hundreds of business applications. 

Both Oracle Jipher and Oracle Linux will leverage OpenSSL 3.5, which introduces support for ML-KEM (for use in TLS 1.3 and other protocols), ML-DSA, and SLH-DSA. The post-quantum cryptography capabilities will be made available in Oracle Jipher as soon as they are FIPS validated. Oracle Linux will offer OpenSSL 3.5 with PQC supported in Oracle Linux 9.7 and Oracle Linux 10.1 releases.

Recommendations to Oracle customers: Preparing for post quantum cryptography.

Oracle recommends that customers:

  • Review their crypto strategy starting with their most critical systems.
  • Move to TLS 1.3 now!
  • Follow PQC standards rather than investing in non-standard solutions. Many current initiatives may be short-lived and result in wasted investments.
  • Be wary of sweeping claims made by commercial or open-source entities. There is currently no ultimate “one size fits all” solution for post quantum cryptography.
  • Finally, application developers should consider the presence of third-party components in their applications, as those may be updated or phased out.
  • Java users should refer to the previous sections of this blog and update to current Java releases!

For more information: