Which Post Quantum Cryptography (PQC) Algorithm Should I Use?

Many New Post Quantum Cryptography (PQC) Algorithms

The quantum threat has been over the crypto space like the sword of Damocles for a while now. The development of a cryptographically relevant quantum computer (CRQC), which will be able to break traditional encryption, “is progressing rapidly” [source].

This is nothing new to people working in the cyber field. They are all aware of the “harvest now, decrypt later” concept. Nevertheless, we need to act now. NIST has standardized a couple of Post-Quantum Cryptography (PQC) algorithms [source].

If you have a closer look, you will realize they are quite a few. So, which one is to be used? This is quite confusing even for experts that have focused solely on classical encryption of data so far.

The transition to the best PQC algorithm is definitely not a trivial task; nevertheless, something you cannot avoid. For example, the NSA forbids acquisitions for national security systems (NSS) that are not compliant to CNSA 2.0 after 1st of January 2027 [source].

The Quantum Safe Financial Forum (QSFF) actually recommends migrating to PQC already in 2025 [source].There are several other initiatives recommending/demanding the implementing PQC algorithms right now.

Figure 1: Confusing Variety of New PQC Algorithms

These details are added in the sections below, which cover the respective cryptographic operation.

How to Select the Correct PQC Algorithm

So, the question is, which algorithms should be used? There are so many new ones. And which of the old ones are not affected and can still be used? Luckily the NSA had come up with some guidelines, which is the Commercial National Security Algorithm (CNSA) 2.0 suite [source]. The approved algorithms are listed in Table 1.

Table 1: CNSA 2.0 Suite Algorithm

The content of this table provides some direction on which algorithm shall be used for what. But it is a bit hard to digest and does not paint the full picture. It leaves out some important details, which are necessary to understand the situation and really select the correct algorithm.

These details are added in the sections below, which cover the respective cryptographic operation.

Data Encryption

The only CNSA 2.0 approved data encryption algorithm is AES. This is the same as in traditional cryptography. AES is not as periled to a CRQC as asymmetric algorithms are. However, running Grover’s algorithm on a CRQC will decrease the security of an AES key by half. Therefore, you will need to increase the key size.

To be on the safe side, use the key size 256 [source]. Figure 1 depicts the currently recommended data encryption algorithms at the top and the only PQC approved data encryption algorithm at the bottom.

Figure 2: Approved PQC Data Encryption Algorithm

For authenticated data encryption, use AES256-GCM (Galois Counter Mode) with a random IV [source, section “How should submitters choose symmetric algorithms for their submissions?”].

Key Establishment

For key establishment, typically DH, ECDH or RSA is used. Key establishment means that two parties agree on a common session key to e.g. encrypt data. This process is also known as key agreement or key encapsulation. As shown in Figure 3, the only PQC approved algorithm is ML-KEM.

Figure 3: Approved PQC Key Establishment Algorithm

All currently used asymmetric key establishment algorithms are prone to Shor’s algorithm. If a sufficiently capable CRQC is available, the current asymmetric algorithms will be broken.

ML-KEM is the only approved PQC key encapsulation mechanism currently. In case a weakness is found in ML-KEM, we will face a problem. Therefore, NIST has selected another algorithm for key encapsulation, which is HQC. NIST plans to issue a finalized standard for this algorithm in 2027 [source]. Till then ML-KEM is the only choice.

Digital Signing

When it comes to digital signing, the situation is a bit more complicated. Currently, the predominant algorithms are ECC, RSA and DSA. There were a couple of new PQC signature algorithms standardized in CNSA 2.0 and the question is which one to use. As a rule of thumb, you can pretty much always go for ML-DSA. There are just a few exceptions, which are detailed in Figure 4. This diagram also features the decision-making process.

Figure 4: Approved PQC Digital Signing Algorithms

Alternative approved signing algorithms to ML-DSA are XMSS and LMS. They are only intended for code signing. So, what makes these algorithms so adequate for code signing? The reason is that signature verification is very fast as these algorithms do not require a lot of resources for verification. This makes these algorithms ideal for signature verification on restricted hardware.

If you need a signature algorithm for code signing, you still need to decide whether you want to focus on speed or security. XMSS has an additional security property. It does not rely on collision resistance of the underlying hash function. On the other hand, LMS is faster.

Please note, LMS and XMSS are stateful signature algorithms. Each calculated signature changes the state of such a key. This makes transferring a key much more difficult. A replication of the signing key to another signature device may incur much more effort.

So, check that key replication of the signing key is not an issue, before selecting LMS or XMSS.

Besides all the things that were mentioned here, under some circumstances, you may need to consider the key length, signature size, key generation time and signature calculation and verification time. They differ a lot from current algorithms.

Mostly, the new algorithms have bigger key size, the signatures are longer, and the calculation of keys and signatures take longer.

As a lookout on the digital signing space, NIST is still standardizing new PQC algorithms. SLH-DSA such an example. But it is not part of the CNSA 2.0 suite yet.

Hashing

The current hashing algorithms as such are okay for PQC. However, their security is weakened by a CRQC, in particular by the Grover’s algorithm, pretty much like AES. Therefore, the size of the hash must be increased.

Figure 5 shows the currently used algorithms at the top and the CNSA 2.0 approved algorithms at the bottom. It clearly shows that you should use at least SHA-384 of the SHA-2 family. For highest security, you can use SHA-512. SHA-1 is not to be used at all.

Figure 5: Approved PQC Hashing Algorithms

But what about the SHA-3 family. It is specifically useful for hashing on hardware. CNSA 2.0 approves it for this specific use case, as it proves to be beneficial for operations on hardware.

Figure 6 shows current SHA-3 algorithms, and the ones supposed to be used in the PQC world.

Figure 6: Approved PQC Hashing Algorithms on Hardware

Similar to the SHA-2 family, the minimum approved hash size is 384 bits. For highest security use SHA3-512.

Of course, there is an exception to the rule. The generation of LMS and XMSS keys relies on hashing algorithms as well. The approved hashing algorithm parameters are listed in NIST SP 800-208.

This publication does allow hashing algorithms like SHA-256 for key generation, which are not approved for generic hashing in the CNSA 2.0 suite as mentioned in this chapter. This may appear confusing.

Anyhow, just stick to the guidelines. For key generation of LMS and XMSS, SHA-256 is fine. If you want to hash something yourself, use a longer hash, as described in this chapter.

Fortanix DSM Supports Full CNSA 2.0 Suite

Fortanix supports the full CNSA 2.0 suite in its Key Management System (KMS) called Data Security Manager (DSM). Therefore, using DSM, you are ready to go for the migration to PQC algorithms in your organization.

Fortanix eases the migration due to its crypto-agile key management capabilities. What is more, all your keys are kept inside a FIPS 140-2 Level 3 compliant Hardware Security Module (HSM).

Of course, the migration of your applications to PQC will require some work at your end and also, your application providers will need to support PQC algorithms as well. But you need to start.

And Fortanix is happy to support you in your PQC migration process. To ease your journey, Fortanix provides a solution to scan your own keys in the cloud and on-premises and further to assess the PQC readiness of your keys.

This solution will help you tremendously to create your own Crypto Bill of Material (CBOM) and have a clear oversight of your required steps to be PQC compliant. This solution is called Key Insight.

For more information, please contact Fortanix.