Preparing For The Post-Quantum Cryptography Era

Cryptography is everywhere. You use it when you unlock your phone, send a message, and make a purchase online. Cryptography is what gives us privacy, trust, and secure communication in our digital world.

But is this all about to change? While quantum computing is still developing, and no quantum computer today can yet break real-world cryptography, the progress is undeniable. NIST and other experts are warning that organizations need to start planning for the post-quantum era now, including beginning to switch to cryptosystems believed to resist analysis by quantum computing.

So, what exactly makes quantum computing so disruptive? And more importantly, what should you start doing today to be ready for tomorrow?

What is quantum computing all about?

Quantum computing introduces an entirely different approach to performing mathematical calculations. With this new model, some mathematical problems that were once considered extremely difficult become much easier to solve (e.g., integer factorization or discrete logarithm problems). The difficulty in solving these math problems is what our current cryptography relies on. This property makes them computationally infeasible to break with current technology, providing the basis for establishing secure communication, verifying identity, protecting sensitive information, and so on. But if a quantum computer can solve these “hard problems” with ease, then the cryptographic foundations we rely on may (or will) become obsolete.

Let’s be clear, a quantum computer that can break today’s cryptography (aka CRQC, Cryptographic-relevant Quantum Computer) is still years away. Some say it’ll take 5–10 years, while others believe it will take longer. (See Report on Post-Quantum Cryptography by NIST – Page 6 and TheVerge – Google says its breakthrough quantum chip can’t break modern cryptography)

So, why act now? Because migrations take time, and a sudden breakthrough could leave no time to react, potentially rendering our current cryptographic foundations obsolete overnight. Additionally, even though CRQC doesn’t exist yet, the “harvest now, decrypt later” attack can be initiated now and harvested data can be decrypted once CRQC does exist, so the risk is already real. We’ll delve deeper into this attack later.

The bottom line is that starting early means staying ahead and avoiding last-minute chaos, giving you the time to prepare appropriately, fix mistakes, and thoroughly test new cryptographic systems, ensuring a smoother and safer transition.

Post Quantum Cryptography

Fortunately, some mathematical problems remain extremely hard to solve, even for powerful quantum computers. This fact forms the foundation of post-quantum cryptography.

To proactively address the coming challenge, NIST initiated the Post-Quantum Cryptography (PQC) project in 2016, aiming to identify and standardize algorithms that can resist quantum attacks.

It’s important to understand that not all classical cryptographic algorithms are vulnerable. The most significant risk affects public-key cryptography, also known as “asymmetric” algorithms (such as RSA and ECC), while symmetric-key algorithms, like AES, likely remain secure when using sufficiently large keys.

So, PQC is not a single solution but rather a growing family of new algorithms, along with recommended configurations of certain existing ones, designed to secure communications in the quantum era.

If there’s one thing past experience has taught us, it’s that cryptographic migrations are rarely simple; instead, they’re time-consuming, complex, and full of unexpected challenges.

Let’s take a quick look at the transition from DES, an older symmetric encryption standard that became vulnerable, to AES, a stronger and more secure symmetric encryption standard, to understand just how prolonged a cryptographic migration can be. NIST began the search for a DES replacement as early as 1997, and it was formally deprecated by 2005. Yet despite being widely recognized as insecure for nearly two decades, DES continues to exist in real-world systems.

In fact, NIST published this document just last year, which says: “18 years later, law enforcement and public safety agencies across all levels of government continue to use DES—a compromised and insecure encryption algorithm.”

The Risks

As mentioned earlier, beyond the risk of waking up one day to find that the cryptography we depend on is suddenly broken, there are other urgent reasons to act quickly.

One of the biggest is the “Harvest Now, Decrypt Later” attack, where attackers collect encrypted data today and store it, waiting for powerful quantum computers to decrypt it in the future. This is especially dangerous for sensitive data that must remain secure for years to come, making future decryption still valuable to attackers. In other words, if your data is not yet PQ-safe, someone might already be collecting it. (see NIST IR 8547 ipd: Transition to Post-Quantum Cryptography Standards)

On the other hand, user and machine authentication algorithms are not subject to the “Harvest Now, Decrypt Later” attack. That’s because future quantum computers don’t affect the authenticity we verify today. So, the risk is real only if the CRQC already exists while verifying the signatures, after all, integrity is not at risk if no CRQC can break it yet, right?

Unfortunately, that doesn’t mean you can sit back and relax, because migrations of digital signature algorithms can be even more challenging than encryption.

The Solutions

In 2022, NIST announced several leading PQ-safe algorithms, including Kyber (for encryption and key exchange) and Dilithium (used for digital signatures), among others.

But not all candidates survived. SIKE (aka SIDH), once considered promising, is no longer considered secure. This serves as a reminder that post-quantum cryptography is still evolving. We must continue to test, adapt, and improve because the algorithms we trust today might one day be proven unsafe.
NIST has recently updated its list of selected post-quantum algorithms for public comment. It’s strongly recommended to monitor these updates regularly, as changes may impact implementation and migration plans.

The currently-recommended approach for migration is to use hybrid cryptography, which combines classical, well-tested algorithms with post-quantum ones during the transition from pre-quantum to post-quantum systems. This method protects secrets even if a post-quantum algorithm is later found to be vulnerable (post-quantum algorithms are still maturing, after all). However, it comes with higher overhead and complexity. Despite these challenges, hybrid cryptography effectively reduces risk throughout the migration process.

For both new and existing projects, it is advisable to adopt quantum-safe cryptography as soon as possible. New projects should use PQC by default, ideally with a hybrid approach, until the field becomes more mature. For existing systems, establish a clear migration plan that prioritizes critical cryptography first. Aim to update less critical systems within 5 to 10 years, in line with NIST’s deprecation tables, as outlined in NIST’s Transition to Post-Quantum Cryptography Standards (lines 488 and 503).

The Checkmarx SAST solutions, including CxSAST on-prem and Checkmarx One, will shortly have tests designed to highlight uses of encryption and signing algorithms and configurations known to be unsafe for post-quantum cryptography.

Areas to Focus On

KEMs

KEMs (Key Encapsulation Mechanisms) enable the establishment of a secure symmetric communication channel, even if an attacker intercepts the initial communication. This security relies on KEMs being public-key cryptosystems, which are vulnerable to post-quantum (PQ) risks. Therefore, traditional KEM algorithms must be replaced with hybrid schemes that combine both classical and post-quantum algorithms. As mentioned earlier, failing to do so may expose the derived secret keys to the “harvest now, decrypt later” attack, putting the symmetrically encrypted data at risk.

The following example demonstrates how to generate an AES symmetric key in Java 21 using BouncyCastle and ML-KEM, a post-quantum-safe key encapsulation mechanism. As discussed above, this is a secure and standards-compliant method for generating and exchanging symmetric keys in the post-quantum era.

Let’s break down the following code sample from the BouncyCastle PQC Almanac (which also provides other useful PQC code samples in Java and C#).

Step 1: Generating the AES Secret Key on the Receiver Side

Security.addProvider(new BouncyCastleProvider());

// Returns a KeyPairGenerator object that generates public/private key pairs 
// for the specified algorithm (ML-KEM) and provider (BouncyCastle).
KeyPairGenerator g = KeyPairGenerator.getInstance("ML-KEM", "BC"); 

// Initializes the key pair generator with the given parameter set and source of randomness.
g.initialize(MLKEMParameterSpec.ml_kem_768, new SecureRandom());
KeyPair kp = g.generateKeyPair();

// Get the public key from the key pair
PublicKey pkR = kp.getPublic();

// Specify we want a 128-bit AES key
KTSParameterSpec ktsSpec = new KTSParameterSpec.Builder("AES", 128).build();
KEM kemR = KEM.getInstance("ML-KEM");

// Using private key to retrieve the AES secret key
KEM.Decapsulator d = kemR.newDecapsulator(kp.getPrivate(), ktsSpec);
SecretKey secR = d.decapsulate(em);

Step 2: Generating the AES Secret Key on the Sender Side

Security.addProvider(new BouncyCastleProvider());

// Returns a KEM object that implements the specified algorithm.
KEM kemS = KEM.getInstance("ML-KEM");

// Specify we want a 128-bit AES key using the same public key (pkR) generated by the receiver
KTSParameterSpec ktsSpec = new KTSParameterSpec.Builder("AES", 128).build();
KEM.Encapsulator e = kemS.newEncapsulator(pkR, ktsSpec, null); // `pkR` is assumed to be accessible since it's a public key

// Retrieving the secret key from the encapsulation
KEM.Encapsulated enc = e.encapsulate();
SecretKey secS = enc.key();

Each of these secret key retrievals happens on a different end (i.e., sender/receiver); eventually, both secret keys have the same value, which means secS equals secR and can be used for symmetric encryption.

Public-Key Encryption and Digital Signatures in Your Codebase

The situation is a bit different with digital signatures. Those rely on long-lived trust anchored in persistent keys or certificates, which increases the complexity and cost of transitioning but reduces urgency, as the risk becomes practical only once a sufficiently powerful quantum computer (CRQC) exists. This provides more time for careful preparation.
Remember, digital signatures are no exception, and using hybrid algorithms during the migration period is strongly recommended.

Transport Layer Security (TLS)

Public-key cryptography is what drives the TLS handshake, which secures nearly all HTTPS traffic today. As we’ve already discussed, using the hybrid approach also in TLS key exchanges ensures continued security even if a weakness is later discovered in one of the algorithms in use.

• On the server side, the goal is to ensure that the PQ hybrid TLS handshake is supported. For example, you can refer to this GitHub discussion to see how OpenSSL can be used to create a PQC certificate. An alternative approach is to leverage third-party services that have already adopted PQC by default. Some infrastructure providers now offer hybrid TLS handshakes, combining classical and post-quantum algorithms, over TLS 1.3.
• Ensuring your clients are also PQ-safe is essential. Even if your server supports post-quantum TLS, the connection isn’t safe if the client doesn’t support this. Luckily, Chrome (reference) and Firefox (reference) already support TLS 1.3 with PQC, so if you’re using either of these, you’re probably on the safe side. But HTTP clients don’t stop at the web-browser level. Don’t forget to protect your code-based HTTP clients, as they also require configuration.
  For example, there’s a quick AWS demo that shows how to set up the Java AWS SDK 2.0 with PQ TLS.

Low-Risk Areas

Before we proceed, it’s worth clarifying that some areas are considered less vulnerable to post-quantum risks, like:

• Symmetric Algorithms
• KDFs
• Hash functions

However, it remains essential to verify that the algorithms employed not only withstand traditional cryptographic threats (e.g., deprecated algorithms, timing attacks, collision-prone hashes) but are also correctly configured where needed, such as using adequate key lengths, proper iteration counts, appropriate salting, and similar measures.

Another technology that heavily relies on cryptography is blockchain (cryptocurrencies, remember?). While the risk is substantial, we have placed it here because the responsibility for addressing post-quantum issues lies with the core blockchain developers and maintainers, not with users or developers building on top of it. That said, it’s still important to keep an eye on developments in this space, as new challenges could emerge that these technologies might not be able to handle, which can put your cryptocurrencies at risk.

Best Practices

Inventory Your Cryptography

Begin by conducting a comprehensive audit of your systems to identify all cryptographic algorithms and libraries in use, including those embedded directly in your code or introduced through third-party dependencies. Having a clear understanding of your cryptographic uses and requirements is essential for planning an effective and seamless migration. Tools like Checkmarx can assist by using built-in queries to map your cryptographic functionality, making it easier to see what needs replacing and where existing implementations are already sufficient.

Stay Updated on Standards and Industry Guidance

Keep an eye on evolving standards from NIST, as well as recommendations from IETF and browser vendors. PQC standards are still maturing, and staying informed ensures your implementation remains aligned with best practices and emerging threats.

Remember: don’t reinvent the wheel. Past attempts to do so without relying on established standards have often led to vulnerabilities and setbacks. Following proven guidance helps avoid repeating those mistakes.

Leverage Hybrid Cryptography Thoughtfully

Consider using hybrid cryptography as a transitional strategy that combines classical and post-quantum algorithms. It has trade-offs, but that extra layer of protection might save your data if one algorithm fails, like SIKE/SIDH did.

Take Care of Your Dependencies

1. Utilize well-established libraries that are starting to integrate post-quantum cryptography (PQC) support, such as Bouncy Castle, which provides implementations of several NIST-selected algorithms. Avoid relying on experimental or unproven libraries, as they may introduce vulnerabilities or lack sufficient community support.
   As a side note, you may come across the liboqs library, which provides bindings for various programming languages. While it may be tempting to use it, checking the limitations section on their website (as of this writing) reveals they explicitly do not recommend using liboqs in production environments.
2. Monitor your dependencies carefully to ensure that none of the software you rely on, such as frameworks, uses broken or PQC-unsafe cryptographic methods internally. Even if these dependencies are not cryptographic libraries themselves, their underlying use of insecure or outdated crypto can indirectly put your systems at risk.

Wrapping Up

Quantum computers are coming; it’s only a matter of time. Starting preparations now will help ensure you remain secure as the landscape changes. The Checkmarx SAST solutions, including CxSAST on-prem and Checkmarx One, will shortly have tests designed to highlight uses of encryption and signing algorithms and configurations known to be unsafe for post-quantum cryptography. This will enable our customers to effectively prepare by identifying code where cryptography does not meet post-quantum safety requirements, and setting policy to support a phased rollout of updated algorithms and configurations.

Remember, cryptographic migrations are not instant, and some threats already exist, such as the “Harvest Now, Decrypt Later attack”. If you handle highly sensitive information that must remain confidential for years, time is not on your side; act quickly and focus on the areas that need the most attention.

Begin by mapping all your cryptographic usage, then adopt a hybrid cryptography approach. Prioritize based on risk factors, such as asymmetric versus symmetric usage, encryption versus digital signatures, and the sensitivity and retention requirements of the data. Follow best practices, stay aligned with authoritative guidelines, and regularly monitor for updates.

The sooner you start, the better prepared you’ll be when the quantum future becomes the present.