Post-Quantum Cryptography Keys and Signatures

The following provides an introduction to Post-Quantum Cryptography (PQC) keys and signatures.

Background

Post-quantum cryptography is cryptography that is resistant to the theoretical threat that a cryptographically relevant quantum computer could port. While such a quantum computer does not yet exist, governments and standardization organizations are working towards a migration from classic asymmetric cryptography to new post-quantum cryptography algorithms. The largest actor in this process is the National Institute of Standards and Technology (NIST).

NIST has announced the standardization of three post-quantum cryptography (PQC) algorithms, FIPS 203 for ML-KEM (derived from CRYSTALS-KYBER), FIPS 204 for ML-DSA (derived from CRYSTALS-Dilithium), and FIPS 205 for SLH-DSA (derived from SPHINCS+).

A fourth digital signature standard FN-DSA (derived from FALCON) will follow. In addition, there are two stateful hash-based signature (SHBS) algorithms standardized in NIST SP800-208 and IETF.

EJBCA versions prior to 9.1 supported NIST candidate PQC algorithms Dilithium and Kyber. These algorithms are removed in EJBCA 9.1 and replaced by the NIST approved PQC algorithms ML-DSA and ML-KEM.

Generated Keys and Certificates

Signature algorithms suitable for a CA are:

ML-DSA (derived from Dilithium), FIPS 204
SLH-DSA (derived from SPHINCS+), FIPS 205
Falcon (NIST standard based on FALCON is planned under the name FN-DSA). Non-standardized PQC algorithms are only valid for non-production use.
LMS and XMSS (SP800-208, RFC 8554, and RFC 8391)

When generating a CA in EJBCA, multiple keys and certificates can be generated:

A CA signing key pair and certificate
An encryption key pair, used for encrypting key recovery information
An OCSP signer key pair and certificate
A SCEP encryption key pair and certificate

When using PQC keys, the CA signing key pair will be the PQC key type you select when creating the CA. The CA signing certificate will be signed using your selected signature algorithm. The key recovery encryption key pair must still be RSA.

SCEP does not support PQC yet (February 2026).

Signing large CRLs with PQC algorithms

The new algorithms are generally not hash-and-sign as classic RSA and EC (for example SHA256WithRSA and SHA256WithECDSA) meaning that all data to be signed are sent to the signature function. This can cause problems for signing for example large CRLs using HSMs as the amount of data that can be sent over the network to an HSM is usually limited. Albeit pre-hash versions of ML-DSA and SLH-DSA exist in the FIPS standards IETF have decided to not allow pre-hash ML-DSA and the standard for using SLH-DSA is not yet completed (Feb 2026). See RFC9881 for using ML-DSA, introducing Externalμ-ML-DSA as the selected way to handle signing of large payloads.

Due to the above we recommend early production scale testing of uses cases when using PQC algorithms in order to avoid issues that CRLs can not be created if they grow more than expected. Support for Externalμ-ML-DSA is available with some HSMs but not all so the expected result depends on the exact HSM, and firmware version, being used and the architecture of your solution.

Post-Quantum Cryptography Standards and HSM Compatibility

ENTERPRISE

Standards for using NIST post-quantum algorithms and corresponding HSM support are still under development. LMS/HSS is standardized in PKCS#11 v3.1, ML-DSA, SLH-DSA and ML-KEM will be standardized (without external-mu) in PKCS#11 v3.2. Several REST-based HSMs already support ML-DSA, SLH-DSA, and LMS.

As post-quantum support is introduced across HSMs, implementations will vary between vendors. Support for post-quantum algorithms is therefore vendor-specific and not universally available across all devices.

HSM Support for Quantum-Safe Algorithms

Multiple HSMs support ML-DSA and composite keys and signatures. This list continues to expand as vendors mature their implementations and as interoperability testing progresses. See also Interoperability and Certifications for officially supported HSMs.

HSM Type	ML-DSA	Composite keys and signatures
AWS Key Management Service (KMS)
Entrust nShield Connect 5c
Fortanix Data Security Manager (DSM)
Thales Luna 7
Thales TCT
Securosys Primus HSM and CloudHSM Service
Utimaco u.trust Anchor
Crypto4A QxHSM
I4P Trident

Not all composite algorithm combinations are supported by every HSM. Ensure that both your HSM model and its firmware version support all algorithms included in the selected composite combination.

When using composite signatures, the payload is always hashed before it is sent to the HSM for signing.

Post-Quantum Algorithms

EJBCA currently supports the following post-quantum algorithms for CAs, also supported by Bouncy Castle. This can change rapidly, so check the availability in the EJBCA user interface to be certain of the latest updates.

Keys	Signature algorithm	Comment	Security Level
ML-DSA-44	ML-DSA-44	FIPS-204 in EJBCA 9.1	128 bit
ML-DSA-65	ML-DSA-65	FIPS-204 in EJBCA 9.1	>128 <192 bit
ML-DSA-87	ML-DSA-87	FIPS-204 in EJBCA 9.1	256 bit
Falcon-512	Falcon-512	NIST round 3 since EJBCA 8.1	128 bit
Falcon-1024	Falcon-1024	NIST round 3 since EJBCA 8.1	256 bit
LMS/HSS	LMS/HSS	RFC 8554	128 bit
SLH-DSA-SHA2-128s…to SLH-DSA-SHAKE-256f	SLH-DSA-SHA2-128s…to SLH-DSA-SHAKE-256f	FIPS-205 in EJBCA 9.3	128-256 bit

A comparison of security levels is that RSA 2048 is 112 bit security level, RSA 3072 and P-256 is 128 bit, and P-521 is 256 bit.

Creating Client Certificates

You can also issue normal requests for client certificates using post-quantum keys.

All certificates signed by a post-quantum CA will naturally use post-quantum signatures, regardless of whether the client keys are RSA, ECDSA, EdDSA, or one of the post-quantum algorithms.

Post-quantum KEM keys cannot be used for signature generation, and therefore, PKCS#10 CSRs that require signature proof of possession (POP) cannot be used. Instead, CRMF messages using the RA Verified POP method can be used. Currently, ML-DSA keys are supported for this purpose. Additionally, for ML-KEM keys, CMP using encrCert POP is supported as of EJBCA 9.1. Furthermore, EJBCA supports the following KEM keys for inclusion in client certificates.

Keys	Comment
ML-KEM-512	FIPS-205 in EJBCA 9.1
ML-KEM-1024	FIPS-205 in EJBCA 9.1

Example CSR Generation

To generate a valid sample CSR for your clients, you can use the EJBCA gencsr CLI command. The following provides an example for generating a CSR with ML-DSA-44:

BASH

bin/ejbca.sh gencsr --keyalg ML-DSA-44 --sigalg ML-DSA-44 --subjectdn "CN=mldsa subject"

Issuing certificates with KEM subject public keys

As KEM keys cannot be used to create signatures, you cannot currently create a PKCS#10 CSR with a KEM public key to request a certificate, since a signature is required for proof of possession (POP). The CRMF CSR format supports alternative POP methods, and you can, for example, use CMP with encrCert POP (see CMP). You can also use other mechanisms that do not require PKCS#10 CSRs to issue certificates with KEM keys, such as CA-generated PEM files or WS API plain public keys.

Example:

CODE

ant cmpclient
cd dist/cmpclient
./cmpclient.sh crmf --url http://localhost/ejbca/publicweb/cmp/encrcert --dn "CN=encrCertPOP" --authparam qw --reqnewkeyspec ML-KEM-512 --includepopo --v

Composite Keys

To support the transition from traditional cryptography to post-quantum cryptography, EJBCA supports the use of composite keys, which combine a classical cryptographic key (RSA, ECDSA, or EdDSA) with a post-quantum key (ML-DSA-44, ML-DSA-65, or ML-DSA-87). This approach allows certificates to be protected by both cryptographic components simultaneously during the migration period. For more information, see Managing Crypto Tokens.