The following provides and introduction to Post-Quantum Cryptography (PQC) keys and signatures.
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 of EJBCA 8.1, there is HSM support for Dilithium for a few selected HSMs. Contact us for more information.
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|
|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
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
To learn more abut what it might entail to get ready for PQC, see Post-Quantum Readiness.
To find out more about using the Bouncy Castle Kotlin API, see How to Use the Bouncy Castle Kotlin API.