Quantum computers are expected to deliver exponential speedups for certain specialized problems, such as large-number factorization, while providing little to no benefit for most general-purpose computational tasks.

One of the undesirable impacts of quantum computing is the decline of certain cryptographic algorithms. Since quantum computers will perform specific 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 widely used cryptographic mechanisms, particularly those based on asymmetric techniques, such as, RSA, ECDH, and ECDSA, may become insecure as quantum computing advances. As a result, a broad range of cryptographic applications, including data encryption at rest and in transit, as well as, methods for verifying authenticity, could be affected to varying degrees.

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, it is often stated that quantum attacks reduce the effective security of traditional cryptography and therefore require larger parameters. In the symmetric setting, quantum algorithms such as Grover’s algorithm provide a theoretical quadratic speedup for exhaustive search, which suggests that larger key sizes may be needed to preserve equivalent security margins. As a result, it is often argued that symmetric key lengths and hash output sizes should be increased to compensate for this effect. 

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 configured with post-quantum capable key establishment mechanisms.

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 shorter-term 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, in which malicious actors with significant computing resources could intercept or steal encrypted data.  The data would be stored until advances in quantum technologies allow it to be decrypted. These concerns are contributing to growing interest in adopting post-quantum cryptography strategies today, even though quantum computers are not currently believed to be capable of carrying out practical attacks.

To protect data at-rest 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 further strengthen this second line of defense by increasing symmetric key sizes to preserve security margins in a post-quantum context. In practice, this means favoring AES-256 over shorter key lengths for protecting data at rest. 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 artifacts, including long-lived artifacts. Examples of long-lived artifacts 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 artifacts over long periods of time (measured in years for legal documents). Consider also that digitally signed firmware underpins other critical security mechanisms. For example, secure boot mechanisms implemented through the Unified Extensible Firmware Interface rely on cryptographic verification to ensure firmware integrity and authenticity.

Therefore, as cryptographic mechanisms evolve to resist quantum-based attacks, it remains essential to preserve verification methods that ensure long-lived documents remain verifiable throughout their intended lifecycle.

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 have implemented 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 has already developed post-quantum cryptography solutions within core technologies such as Oracle Java and Oracle Database and continues to enhance them, making adoption easier for customers while seeking to 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 continues to use AES-256
  • Data in transit encryption is shifting to leverage hybrid key-exchange, with an option to use pure PQC key-exchange.
  • Oracle is implementing FIPS 204 ML-DSA signatures. This is used in various long term or ephemeral schemes.
  • Over time, as PQC algorithms are implemented and gain broader industry acceptance, Oracle expects to introduce PQC-only certificates. These certificates may be anchored in private CA PQC roots, an approach already supported by Oracle Database, and later include PQC certificates issued by well-known public CAs as they become available.
  • Regarding firmware and long-lived documents signing:
    – During the transition period, and to accommodate varying regulatory requirements across different countries, Oracle plans to use classical and post-quantum cryptographic signatures side by side for firmware signing where feasible. Specifically, Oracle’s objective is to align with existing U.S. government requirements, include Commercial National Security Algorithm Suite 2.0 (CNSA 2.0), by incorporating stateless or stateful hash-based digital signatures within hardware security modules, in a manner consistent with the intended security assurance level of the 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

Oracle AI Database 26ai integrates the cryptographic algorithms necessary to help protect your database against quantum attacks. The key features included in this release are:

  • Support for selected quantum-safe cryptographic algorithms for key exchange and digital signing: ML-KEM for key exchange / ML-DSA for signing and verification
  • Support for TLS to utilize quantum-safe key exchange algorithms to encrypt traffic between a database client and server.
  • Full support for AES-256 encryption across all Oracle Database features.
  • Support in progress for wide client and certificate ecosystems.

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

    Java

    Oracle’s Java Security Team, through the OpenJDK processes, continues to make progress and gathers feedback to bring PQC enhancements to the Java Development Kit (JDK) via the Java Enhancement Process (“JEP”).

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

    Additionally, new algorithms have already been delivered in JDK releases:

    Oracle has started the development of PQC TLS mechanisms for Java combining post-quantum and traditional algorithms planned to be released in JDK 27. 

    Additionally, Oracle intends in future Java versions:

    • To backport updated TLS mechanisms and PQC support to long term support releases. These backports will be driven by customer demand to enable as much as possible PQC in existing Java applications.
    • To support signing JARs with ML-DSA in JDK 26 which will be released in March 2026.
    • To deliver an API for Hybrid Public Key Encryption in JDK 26. All traditional KEM, KDF, and AEAD algorithm identifiers defined in RFC 9180 are supported. Support for PQC algorithms with HPKE is planned for a future release.

    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 already offers 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:

    • Transition to TLS 1.3 as a prerequisite for enabling post-quantum cryptography for data in-transit.
    • Upgrade to current versions of Oracle products, including Oracle Database, Oracle Java, and Oracle Linux.
    • 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

      For more information: