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 yest 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) and the NIST Post-Quantum Cryptography Standardization Process.

There are currently (May 2023) three NIST draft standards after the NIST PQC competition, FIPS 204 for ML-DSA (Dilithium), FIPS 205 for SLH-DSA (SPINHCS+) and FIPS 204 for ML-KEM (Kyber). Kyber is a KEM and not used for Certification Authorities. Standardization of Falcon is expected to follow in a year or so (late 2024 or -25). 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 the development is moving fast, the algorithms supported by EJBCA at any given moment may change.

Using NIST candidate and draft algorithms (for example, Dilithium, Falcon, SPHINCS+) is suitable for non-production use only. The algorithms and parameters will change when the final standards are published by NIST. There are no official OIDs assigned, currently, temporary ones are used for testing.

Until standardization is completed and final algorithms and parameters are implemented, these are only valid for non-production use.

Until standardization is completed, and final standard algorithms and parameters are implemented, these 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 (NIST FIPS 203 draft standard)
Falcon (NIST standardization process)
SPINCS+ (NIST 205 draft standard)
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 This is an EJBCA Enterprise feature.

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

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

BASH

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

kotlin -cp kcrypto/build/libs/bc-kcrypto-0.0.9.jar:bc-jars-reg/bcprov-jdk18on-173.jar:bc-jars-reg/bcpkix-jdk18on-173.jar:bc-jars-reg/bcutil-jdk18on-173.jar:examples/build/classes/kotlin/main MakePKCS10RequestDilithiumKt