Post Quantum Cryptography Post Quantum Cryptography

Post Quantum Cryptography

Created: Updated:
TOC
- Strategy
- Keyfactor Sources
- Cipher Support
- Timelines
- Migration Plan
- Communications
- HSM/Smartcards/tokens

Quantum-safe overall Strategy

As a PKI Vendor, we see in general that 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 - PQ time snapshot January 2024, and development doesn't stop.

 

Keyfactor Sources

PQC Lab

Keyfactor Post-quantum cryptography lab - Get ready for the quantum leap!

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 YoutTube channel.


Cipher Support

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

A. 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 is released and can be used for testing. Will be updated to next/final version of the algorithms in upcoming releases.
  • SignServer:
    • LMS and Round3 Dilithum and SPHINC+ is 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 track the standards and cooperate with other teams in IETF and NIST. For OIDs and test data used at interoperability hackatons see: https://github.com/IETF-Hackathon/pqc-certificates

 

Q. Is a list of planned ciphers already available?

A. For 2024 we target algorithms that will be standardized during first half of the year, i.e. the NIST algorithms. In this phase of quantum readiness we deem that standardized algorithms is of most public interest.

 

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

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

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

 

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

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

LMS is supported for signing in 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 exception) 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.

 

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

A. 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.

 

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

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

 

Timelines

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

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

 

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

A. This is already available. See documentation and tutorial videos above.

 

Migration Plan

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

A. 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.

 

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

A. Yes

Bouncy Castle support three proposed variants: ITU-T X.509 (published standard), Composites (IETF draft) and Chameleon (IETF draft).

EJBCA support issuing hybrid certificates in the ITU-T X.509 standard format. This is not released in a production release, but is in testing by selected customers. Contact us if you are interested.

 

Communications

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

A. This questions 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 need to support it, i.e. web browsers, OpenSSL, Bouncy Castle, WolfSSL, etc.

 

HSM and Tokens

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

A. Yes we work closely with multiple HSM vendors.

 

Q. Is HSM integration for quantum-safe algorithms already available?

A. 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, i.e. when EJBCA support the final version of Dilithium we need to wait until HSM vendors also support the final version.

 

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

A. This is not tested, and 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 like PKCS#11, CSRs, CMP, etc. If the tokens produce proper signatures they will produce proper CSRs, and thus be interoperable.