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

Overall, I agree with a lot of the sentiment and the statements thus far. One key aspect I think we need to ensure is that we don't silo discussions to a specific topic or for example ssh keys. In other words, ultimately the *complete* scope of work remains undefined, and projects *should* identify potential areas of work that they can see, while the overall larger ecosystem moves forward and the overall exact needs are clarified further. The wider process should be to revise a vision and guidelines as time moves forward. For example, it could boil down to a very simple question for projects: Does your project do *anything* in relation to keys, encryption, or interaction of any encrypted data either at rest or while in transit.? If yes, are there actions to take? And then a dialog needs to occur, or at least a framework for understanding if there *really* needs to be an investment in time or resources in that specific instance of usage, or is it just permitting a longer value, or what. Ultimately that is a case by case assessment which needs to be performed. A good first step for any working group would be to create a chart which could be used as a reference for those individual discussions. -Julia On Mon, Oct 27, 2025 at 5:35 AM Sean Mooney <smooney@redhat.com> wrote:

my personal take on this is it may be a vaild future comunicaty goal but its probably premature.

in general most openstack project try to not be in the busyness of Cryptography if we can at all avoid it.

our dependicies may have cypto feature like ssh, ssl for our rest apis or similar both the openstack code base in general tries to not implement any cypto logic itself. i.e. we try to delegate to python-cryptography or similar well maintained modules.

for example just looking at the nova section you mentioned that nova can genreate ssh keys

https://wiki.openstack.org/wiki/Post_quantum_openstack#Nova_.28Compute.29

however we deprecatea and removed that capablity in zed relese in micoversion 2.92

https://docs.openstack.org/nova/latest/reference/api-microversion-history.ht...

we did that specificly because we did nto want to supprot ssh key generation in nova going forward and defiend that to be out of scope fo our project

so that is a non issue in a PQC world because we have decieed as a project not to extend or suprot that api going forward.

it has not been removed as we dont do that in nova if its reasonable to keep the code but it shoudl never be used anymore.

we only supprot uploading a pre generated public key now.

the there two case might be valide

```

Supports validation of Glance image signatures and certificate trust when booting signed images. (link)

Metadata path protection with Neutron uses HMAC over Instance-ID to prevent spoofing (shared secret). (link)

```

although for the metadata case that shared secretae is intened to be passed over a https connection so if the ssl encyption for the connection supprot post quantum encyption then the hamc does not really need too but we can likely change that algorhtypme when python cypgoraphy supprot somethign in the future that is a suitable replacement.

the glance image verficaiton woudl need glance to support somethign else instead but if they come ups with an updated approch nova coudl adapt.

none of the above seem particularly urgent and likely don't need to be addressed in 2026.1 or even 2027.1 but if someone wanted to write a spec for the nova/glance changes and wanted to work on it it could be reviewed via the normal upstream process without needing to make it a comunity goal or have it driven by the TC. you coudl for example create a popup team or sig kind of like the eventlet remvoal work to drive this instead.

speaking of which i think the eventlet removal work is gong to take precedence for most team as that is more urgent in terms of real world impact.

regards

sean.

On 27/10/2025 05:14, Goutham Pacha Ravi wrote:

...

On Fri, Oct 24, 2025 at 1:19 PM Jean-Philippe Jung <jjung@redhat.com> wrote:

...

Hi,

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

Thank you for starting this discussion, JP. I've added a topic to the TC's PTG for 1600 UTC on Friday, 31st Oct 2025. I hope you'll be able to share your findings there briefly and invite opinions in-sync. Our vehicle for driving cross project work has been via the Community Goals framework: https://governance.openstack.org/tc/goals/ If we have one or more objectives, this can be proposed as one, and will require a "goal champion" - someone that'll help us gather requirements, and coordinate efforts to complete the goal. Some goals in the past have spawned new groups - either as Pop Up Teams or SIGs (https://governance.openstack.org/tc/reference/comparison-of-official-group-s...).