Post-Quantum Cryptography Keys and Signatures

The following provides and 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 supports a variety of post-quantum algorithms for experimentation and testing. As development is moving fast, the algorithms supported by EJBCA at any given moment may change. Keyfactor is committed to supporting our customers through the transition to the new PQC standards and is working to adopt the final standards into our solution stack.

Until final standard algorithms and parameters are implemented, the pre-standardized PQC algorithms are only valid for non-production use. Any installation using these algorithms will break when the final algorithms are implemented, and the system will not be interoperable with the final NIST algorithms.

Post-quantum algorithm support is offered for experimentation and testing and with limited support (SLA).

Generated Keys and Certificates

Signature algorithms suitable for a CA are:

Dilithium (ML-DSA), FIPS 204
SPHINCS+ (SLH-DSA), FIPS 205
Falcon (NIST draft standard based on FALCON is planned for late 2024)
LMS and XMSS (SP800-208, RFC 8554, and RFC 8391)

When generating a CA in EJBCA, up to three keys and certificates are 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

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 encryption key pair must still be RSA.

OCSP signing is not yet supported using PQC, EC and RSA must still be used.

Using Post-Quantum algorithms with an HSM

ENTERPRISE

There is currently no standard in PKCS#11 for using the NIST draft post-quantum algorithms and HSM support for post-quantum algorithms is not yet available. LMS/HSS is standardized in PKCS#11 v3.1.

As post-quantum support for HSMs is added, it is important to note that this will be using vendor-defined mechanisms differing between different HSM vendors. Thus, the HSM support will be tied to specific vendors and will not be general for all HSMs.

As of EJBCA 8.1, there is HSM support for Dilithium for a few selected HSMs. Contact us for more information.

Post-Quantum Algorithms

EJBCA currently supports the following post-quantum algorithms, 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
Dilithium2	Dilithium2	NIST round 3 in EJBCA 8.0/8.1	128 bit
Dilithium3	Dilithium3	NIST round 3 in EJBCA 8.0/8.1	>128 <192 bit
Dilithium5	Dilithium3	NIST round 3 in EJBCA 8.0/8.1	256 bit
Falcon-512	Falcon-512	NIST round 3 in EJBCA 8.0/8.1	128 bit
Falcon-1024	Falcon-1024	NIST round 3 in EJBCA 8.0/8.1	256 bit

A comparison of security levels is that RSA 2048 is 112 bit security level, RSA 3072 128 bit, and P-256 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 as such PKCS#10 CSRs that require signature proof-of-possession (POP) cannot be used. CRMF messages, using the RA Verified POP method can be used. Currently, NTRU keys are supported for this.

Example CSR Generation

To generate a valid sample CSR for your clients, the Bouncy Castle Kotlin (bc-kotlin) tool can be used.

The following outlines a basic example of generating an NTRU KEM key and getting it certified by a CA using the CMP protocol, using the EJBCA cmpclient to send the request

BASH

kotlinc -cp kcrypto/build/libs/bc-kcrypto-0.0.9.jar:bc-jars-reg/bcprov-jdk18on-173b12.jar:bc-jars-reg/bcpkix-jdk18on-173b12.jar:bc-jars-reg/bcutil-jdk18on-173b12.jar -script ./scripts/ntru-key.kts 

./cmpclient.sh crmf --dn "CN=cmp1" --authparam password --reqpublickey ntrupub.pem --url http://localhost:8080/ejbca/publicweb/cmp/cmppq

The following provides an example for generating a CSR with Dilithium2: