[tc][all][security] Supporting Post-Quantum Cryptography in OpenStack code (all projects)
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
Hi Jean-Philippe, Very interesting topic. OpenStack and their code/libraries are well covered in this wiki post, but how about the infrastructure (for example SSH servers, installed via OS packages on the Cloud hosts)? What about OpenStack development (for example SSH server behind the Gerrit Code Review system)? On Fri, Oct 24, 2025 at 11:19 PM Jean-Philippe Jung <jjung@redhat.com> wrote:
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.
-- Regards, Maksim Malchuk
On Fri, Oct 24, 2025, at 1:59 PM, Maksim Malchuk wrote:
Hi Jean-Philippe,
Very interesting topic. OpenStack and their code/libraries are well covered in this wiki post, but how about the infrastructure (for example SSH servers, installed via OS packages on the Cloud hosts)?
OpenSSH 10 will use mlkem768x25519-sha256 for key agreement by default. Earlier versions of OpenSSH have some support for these algorithms, but looks like version 10 is where you should start to see them used by default.
What about OpenStack development (for example SSH server behind the Gerrit Code Review system)?
Gerrit uses the MINA SSHD which added support for ml-kem in version 2.15.0 via bouncy castle. Gerrit 3.12 includes MINA SSHD 2.15.0.
On Sat, Oct 25, 2025 at 12:15 AM Clark Boylan <cboylan@sapwetik.org> wrote:
On Fri, Oct 24, 2025, at 1:59 PM, Maksim Malchuk wrote:
Hi Jean-Philippe,
Very interesting topic. OpenStack and their code/libraries are well covered in this wiki post, but how about the infrastructure (for example SSH servers, installed via OS packages on the Cloud hosts)?
OpenSSH 10 will use mlkem768x25519-sha256 for key agreement by default. Earlier versions of OpenSSH have some support for these algorithms, but looks like version 10 is where you should start to see them used by default.
OpenSSH 10 is a great solution, but the question is how to deal with current OSes? For example Ubuntu 24.04 (current LTS) still uses OpenSSH 9.6, but MLKEM support was added only in the OpenSSH 9.9. Should we use backports? or wait for 25.04 support in deployment tools and do an upgrade?
What about OpenStack development (for example SSH server behind the Gerrit Code Review system)?
Gerrit uses the MINA SSHD which added support for ml-kem in version 2.15.0 via bouncy castle. Gerrit 3.12 includes MINA SSHD 2.15.0.
-- Regards, Maksim Malchuk
On 2025-10-25 00:49:30 +0300 (+0300), Maksim Malchuk wrote: [...]
OpenSSH 10 is a great solution, but the question is how to deal with current OSes?
For example Ubuntu 24.04 (current LTS) still uses OpenSSH 9.6, but MLKEM support was added only in the OpenSSH 9.9. Should we use backports? or wait for 25.04 support in deployment tools and do an upgrade? [...]
This sounds like a great question for your operating system vendor. I don't think the OpenStack community can solve that problem for you (nor should we try to). Being flexible and adaptive to the ever-changing security landscape is something we should aspire to regardless, and doesn't require a quantum boogeyman to make it so. We can work on keeping OpenStack secure, and let the people who make operating systems work on keeping those secure, whether it's from quantum key factoring at some point in the (impossible to predict) future, or the very many actual real-world threats we all face today. -- Jeremy Stanley
On Sat, Oct 25, 2025 at 1:20 AM Jeremy Stanley <fungi@yuggoth.org> wrote: This sounds like a great question for your operating system vendor.
I don't think the OpenStack community can solve that problem for you (nor should we try to).
This is not really related to only my (lol) operating system vendor. For example, this is related to the two most used OpenStack deployment tools which depend on affected OSes: 1. https://docs.openstack.org/kolla-ansible/latest/user/support-matrix.html 2. https://docs.openstack.org/openstack-ansible/latest/admin/upgrades/compatibi... Both Kolla-Ansible and OpenStack-Ansible support only Ubuntu 24.04 which doesn't contain even 9.9 OpenSSH. -- Regards, Maksim Malchuk
On 2025-10-25 02:57:06 +0300 (+0300), Maksim Malchuk wrote: [...]
This is not really related to only my (lol) operating system vendor. For example, this is related to the two most used OpenStack deployment tools which depend on affected OSes:
1. https://docs.openstack.org/kolla-ansible/latest/user/support-matrix.html
2. https://docs.openstack.org/openstack-ansible/latest/admin/upgrades/compatibi...
Both Kolla-Ansible and OpenStack-Ansible support only Ubuntu 24.04 which doesn't contain even 9.9 OpenSSH.
And you don't ever plan to upgrade to a newer version of OpenStack in the future, or assume that for some reason OpenStack is just going to cease supporting newer LTS distributions once they're available? OpenStack has a policy of testing on the most recent LTS distributions available at the start of each development cycle. That implies, e.g., that OpenStack's 2026.2 coordinated release will target Ubuntu 2026.4 LTS as a tested platform. That's still years ahead of the suggested 2029 "deadline" for PQC support. I'm really unclear on what actual concern you're trying to raise, much less what your plans are to solve them from within the OpenStack community. -- Jeremy Stanley
On Sat, Oct 25, 2025 at 8:25 PM Jeremy Stanley <fungi@yuggoth.org> wrote:
I'm really unclear on what actual concern you're trying to raise, much less what your plans are to solve them from within the OpenStack community.
I'm trying to understand the urgency of the work Jean-Philippe is seeking for, and plan the infrastructure upgrade/support in the near future, not only Openstack code described in the wiki. If we are talking about infrastructure, are we waiting until 2029 when Ubuntu LTS versions will already have supported SSH versions with MLKEM ? If we are talking about the urgency of supporting MLKEM on current SSH versions, then we need to use backports. This means we need to add this now to the current deployment tools. -- Regards, Maksim Malchuk
On 2025-10-26 16:23:45 +0300 (+0300), Maksim Malchuk wrote: [...]
I'm trying to understand the urgency of the work Jean-Philippe is seeking for, and plan the infrastructure upgrade/support in the near future, not only Openstack code described in the wiki.
In my professional opinion, as well as that of the many long-time career cryptographers I interact with[*], "not very urgent." Actual usable quantum computers don't exist today, and when they'll exist depends on physicists making a number of unpredictable scientific breakthroughs. Separate from that, synthetic (emulated) quantum computers don't yet have any viable algorithms for factoring anything more than trivial prime products. Further, nobody knows what novel cryptanalitic attacks any real quantum computer will eventually enable. In short, designing a cryptographic defense against quantum computers is akin to designing an orbital defense against alien invaders. Anyone who claims to know *when* quantum computers will be more usable for cryptanalysis than conventional computers or *how* to thwart them is either selling something or has a working time machine. The market is flooded with PQC snakeoil vendors, so whenever you read their doomsday predictions just try to keep an open mind and don't get caught up in the panic-driven profiteering they're trying to create. There are real security threats *today* that we should be putting more effort into mitigating, which as a side effect can hopefully also make our software more robust against fictional (from the present perspective) quantum computers and space invaders.
If we are talking about infrastructure, are we waiting until 2029 when Ubuntu LTS versions will already have supported SSH versions with MLKEM ? If we are talking about the urgency of supporting MLKEM on current SSH versions, then we need to use backports. This means we need to add this now to the current deployment tools.
OpenSSH 10 is already in Ubuntu 25.10 (non-LTS), so should be included in Ubuntu 26.04 LTS which will be available for testing at the start of the OpenStack 2026.2 development cycle and therefore also a supported target platform for OpenStack 2027.1 (the next SLURP release). By 2029, any OpenStack releases not tested on platforms with OpenSSH 10 will be unmaintained/end of life even. But keep in mind that there are so-called PQC key exchange/agreement algorithms available back to OpenSSH 9.0[**] several years ago (available in the current Ubuntu 24.04 LTS). Don't get me wrong, I agree that we should be taking a close look at the highlighted parts of our codebase. If the quantum computing buzzword gives devs an excuse they can use to convince their managers to let them spend time on this, and makes operators more likely to keep their systems and software upgraded, then that's fine by me. Just don't buy into the industry scaremongering, and make sure to spend these precious resources in areas where they'll provide a tangible benefit whether or not quantum computing ever becomes viable. [*] https://www.metzdowd.com/pipermail/cryptography/2025-February/038625.html [**] https://www.openssh.com/pq.html -- Jeremy Stanley
On Fri, Oct 24, 2025, at 1:06 PM, Jean-Philippe Jung wrote:
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.
While relying on many unmaintained libraries to solve similar problems is an issue, I'm not sure this really articulates why OpenStack needs post quantum crypto support (which specific features are most at risk etc). It also doesn't seem to propose any concrete solutions. From what I can tell https://pypi.org/project/quantcrypt/ is the option within the python ecosystem today. Which actually means the solution here is adding more cryptographic library tooling to OpenStack. Thinking out loud it might be helpful to determine which specific areas of OpenStack are most at risk of having data captured and stored for later decryption efforts then target adding support for quantcrypt provided encryption to those areas. Rather than try and boil the ocean with a complete cryptographic overhaul of OpenStack start with small concrete achievable improvements. Then take what is learned from that process to apply it more broadly. In general bite sized solvable problems tend to get more traction over time compared to massive undertakings that feel insurmountable. This is why I think it would be good to start with something small and achievable that provides real benefit. We can also separately work on cleaning up the reliance on unmaintained libraries, but if we're going to be adding a new library to support this use case anyway then cleanup seems somewhat orthogonal to me. That said I'm not core for any openstack service and I am not on the TC. Others with more direct involvement may have a different perspective.
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.
participants (4)
-
Clark Boylan
-
Jean-Philippe Jung
-
Jeremy Stanley
-
Maksim Malchuk