Hi,

I am the OpenStack Security Product Manager at Red Hat. I also support Post Quantum Cryptography in OpenStack and k8s (well, OpenShift for us), and I cover some areas of confidential computing.

I see one existential risk to OpenStack in the near future: support for post-quantum cryptography (PQC) [0]

Based on my latest discussion with industry experts, I expect that around 2029 (likely) or 2030 (at best), there would be powerful enough Q-Computers to break traditional cryptography. Meaning we have to prepare OpenStack to support post-quantum crypto (ML-KEM urgently, ML-DSA as soon as possible) in the upstream code. As we also need to provide time for operators/customers to implement the "fixed" code, we are in early 2028 territory to achieve sufficient PQC coverage in OpenStack upstream. This would give OpenStack users time to implement this code. Time is running out; we’re already almost in 2026!

A point to keep in mind is that the initial PQC algorithms might fall short and be replaced in the future. Thus, this PQC support exercise should also be a “cryptographic agility” exercise: we should have a few libraries we know how to call, and if a new crypto algorithm comes out, it should be easy to enable it in the code.

I used AI engines to have a look at the OpenStack upstream code (not all projects, but a chunk of the most commonly used), and I came back with 17 different cryptographic modules, 7 of which received no commits in over 2 years. It might be directly in the code or in pulled dependencies. The first step to solving a problem is recognizing we have one. We have a problem.

I am seeking help from the TC to raise the urgency of this work across all OpenStack projects and to help me lead an effort to reduce the number of cryptographic modules used in OpenStack (my personal opinion is that there should be no more than five).

Doing this may involve work in each OpenStack Project team; and I can help organize this effort. I'm seeking the following from the TC and/or project teams:
Portions of this work will be isolated to specific repositories managed by a project team, while others will involve "cross-project" synchronization.
What vehicles can we use to have a "call-to-action" for project teams to get someone to look into their specific projects? How can we go about community wide collaboration?

I've created a document [1] that I assembled from AI analysis of part of the OpenStack code. It gives an overall view of the problem we face.

Looking forward to hearing from you and collaborating upstream to improve OpenStack.

Regards,

Jean-Philippe (JP) Jung
jjung@redhat.com
irc: jjung

[0] Quantum what?
Quantum computers will break current encryption algorithms like RSA and elliptic curve cryptography using Shor's algorithm, exposing all data encrypted today. Adversaries are already harvesting encrypted data to decrypt later once quantum computers mature.
OpenStack powers critical cloud infrastructure globally. Deploying post-quantum cryptography (PQC) upstream is essential because downstream distributions and deployments inherit these security foundations. Without upstream PQC integration, the entire OpenStack ecosystem remains vulnerable, putting sensitive workloads, government systems, and enterprise data at risk. The migration takes years, so implementing PQC now in the codebase is operationally necessary, not optional.

[1] https://wiki.openstack.org/wiki/Post_quantum_openstack