FAQs: Post-quantum cryptography

Created: Updated:

As a PKI vendor, we see in general that post-quantum cryptography (PQC) algorithms will replace classic algorithms. Keyfactor aims to be the best partner for customers during this migration. We are ready today to assist in testing, inventory, and planning for migration. Contact us. We are here to help.

Please note that quantum-readiness is a fast-changing technology area. This Q&A is accurate as of January 2024, and development doesn't stop.

Cipher support

Are quantum-safe algorithms already available for use? If yes, which versions and OIDs?

Yes. There is slightly different algorithm support in different products.

  • Bouncy Castle: Supports virtually all algorithms you can think of.
  • EJBCA: Round3 Dilithium and Falcon are released and can be used for testing. Will be updated to next/final version of the algorithms in upcoming releases.
  • SignServer: LMS and Round3 Dilithium and SPHINC+ are released and can be used for testing. Will be updated to next/final version of the algorithms in upcoming releases.
  • Command: Dilithium and Falcon certificate parsing is implemented for inventory in Command.

Bouncy Castle, which sits as the foundation of our other products, closely tracks the standards and cooperates with other teams in IETF and NIST. For OIDs and test data used at interoperability hackathons, refer to: https://github.com/IETF-Hackathon/pqc-certificates.

Is a list of planned ciphers already available?

For 2024, we target algorithms that will be standardized during the first half of the year, such as the NIST algorithms. In this phase of quantum-readiness, we deem that standardized algorithms are of most public interest.

Will supported ciphers be based on NIST standards or any other (proposed) standard?

NIST standards are what everyone is expecting globally and are what we plan to support initially in EJBCA, SignServer, and Command. They are, to our knowledge, the only relevant standards coming out in the first half of 2024. These are referenced to also be used by others, such as ANSSI and BSI.

The notable exception is BSI working on Classic McEliese (in ISO). Currently, it is uncertain if this will be relevant for PKI, and standardization is still ongoing and not targeted to be ready as soon as the NIST standards. Bouncy Castle already supports classic McEliese and many other algorithms that are not scheduled for standardization (yet).

Will XMSS and LMS be supported? If yes, could you sketch how state management will be done?

Both LMS and XMSS (and multi-tree variants) are supported by Bouncy Castle.

LMS is supported for signing in to SignServer. It is still an open question on potential adoption for PKI. We adopt the NIST strategy for state management and will only allow LMS to be used with an HSM (i.e. the HSM will handle state management).

HSM vendors are in general today not production ready for LMS (although there are exceptions), and there are open questions related to state management (backup, clustering). The industry is currently awaiting updated NSA/NIST guidance on the topic since the last NCCoE workshop where this was discussed.

What is the strategy for updating deployed solutions to new ciphers?

New algorithms will be supported with software updates to existing deployments in the regular update cycle. In Bouncy Castle, it is part of the regular releases. Draft algorithms are already available in EJBCA, SignServer, and Command, also as part of standard releases.

Is it already possible to set-up OSCP Responders/sign CRLs with quantum-safe algorithms?

Yes. You can sign CRLs today. OCSP is not yet available, but will be in the future.

Timelines

What is the timeline regarding the above-mentioned quantum-safe ciphers?

Algorithm and OID updates will come out once NIST releases final standards. Bouncy Castle will release a final version in a software update following the standards. EJBCA and SignServer expect to be ready in the first software release following NIST final standards.

Will there be public alpha/beta versions available for testing even before production support?

This is already available. Refer to the documentation and tutorial videos at the end of this article.

Migration plan

Will there be in-software support for migrating from legacy PKIs to quantum-safe PKIs?

Yes. This is already available for testing with draft algorithm versions in the software that you are running.

Command, our CLM product, supports agile PKI migration from one CA to another and will support the same with PQC algorithms to enable several methods of migration to suit different use cases.

Are hybrid or composite certificates already supported or planned? If yes, according to which specs (e.g., ITU-T X.509)?

Yes. Bouncy Castle support three proposed variants: ITU-T X.509 (published standard), Composites (IETF draft), and Chameleon (IETF draft). EJBCA supports issuing hybrid certificates in the ITU-T X.509 standard format. This is not released in a production release, but is in testing with select customers. Contact us if you are interested.

Communications

Is it possible to set up quantum-safe communication to the CAs/OCSP responders?

This question typically refers to TLS using hybrid key-exchange algorithms. OCSP uses plain HTTP communication without TLS, so there is no need for this.

Bouncy Castle is adding post-quantum hybrid key-exchange to the TLS implementation, to be available soon.

For EJBCA, SignServer, and Command, these products rely on platforms (application/web servers) for HTTPS communication. TLS with post-quantum algorithm support will be seamlessly available once these platforms support it (for example, Apache HTTPd, WildFly, or IIS). The client side also needs to support it (i.e. web browsers, OpenSSL, Bouncy Castle, WolfSSL, etc.).

HSM and tokens

Is there coordination with HSM providers to support the ciphers in their HSMs?

Yes. We work closely with multiple HSM vendors.

Is HSM integration for quantum-safe algorithms already available?

Yes. EJBCA and SignServer already have integration for Dilithium (Round3 version) and LMS, with several HSMs. Note that the period until we and every HSM vendor support the final version of algorithms is bound to be shaky because not everyone will update the algorithm version at the same time. Rather, when EJBCA supports the final version of Dilithium, we need to wait until HSM vendors also support the final version.

Is the usage of quantum-safe certs and keys already tested with available client tokens, or are there plans in this space?

This is not tested and is generally outside the scope of our products.

We do work with token vendors; for example, providing quantum-ready PKI into their testing environments. Client tokens, however, do not directly integrate with the PKI (EJBCA) or signing engine (SignServer). EJBCA and SignServer interact with client tokens using standardized protocols/messages, such as PKCS#11, CSRs, CMP, etc. If the tokens produce proper signatures, they will produce proper CSRs and thus be interoperable.

Resources

Labs

Articles and documentation

Tutorials

A few selected tutorials are linked below. There are more videos and tutorials available in the Bouncy Castle, EJBCA, and SignServer documentation and on the KeyfactorCommunity YouTube channel.

Related articles

Comments

Please sign in to leave a comment.

Back to top