Hi,

Thanks for the comments, and let me try to group some & reply ahead of the PTG session.

1- Quantum computers are no threat, they are underpowered, so what’s the risk & why should we do anything now?

• The issue is time. The day a quantum computer is powerful enough to break traditional cryptography (known as Q-day), it is too late. OpenStack lays naked and vulnerable.
• We can argue about dates, and my current opinion is that to be on the safe side, any software product should implement PQC cryptography by 2029.
• We have a large code base, and we need to give time to the community to review & adjust it then to openstack operators to implement quantum-safe cryptography.
• There is no snake oil/panic-driven agenda here, either we protect access to OpenStack infrastructure & between services, preferably by 2028. Or we don’t. We have time, but we should start work now.

2- It’s a problem for Operating System vendors, we just consume their cryptography.

• I wish it were true. But the initial analysis I made demonstrates we have libraries that do cryptographic operations, and maybe these libraries end up properly calling an OS cryptographic module. Maybe not. I know of paramiko, that does not call any OS layer, but its own copy of OpenSSL code. We cannot assume OpenStack has nothing to do until we analyse our cryptographic usage.
• I totally support the idea of using OS cryptography as much as possible, because we offload the maintenance problem to OS vendors.
• Then because new fancy cryptographic algorithms have been finalized (key encapsulation, ML-KEM), or near finalized (digital signature, ML-DSA) does not indeed mean they are available in all the protocols that uses them (IPsec, kerberos, dnssec…) in operating systems.

3- Some of the libraries listed might no longer be in used.

• The code should be removed from OpenStack. We have customers doing Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST): these will flag those unsafe modules.
• Other side of that point: some of these libraries are still used. Do they rely on an operating system cryptography, or do they pull their own cryptographic call? Are they maintained? Should we reduce the amount of cryptographic modules in OpenStack?

4- There is no plan proposed, what’s next?

• Initial email was to express my concern about supporting PQC in OpenStack, understanding if my concern was shared, and raise awareness on this topic right ahead of the PTG.
• The first step to solve a problem is to know there is a problem, I’d start with a per project effort starting with a 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?"
• Next would be to use those results to plan for protecting OpenStack against the store-now, decrypt-later attacks, meaning protecting key exchanges relaying on ML-KEM (well hybrid X25519MLKEM768 to start with), ensuring symmetric keys are long enough (256 bits minimum), then deal later with digital signatures code (if any).

5- The goal is premature

• I consider this a community goal because all OpenStack components must achieve support pretty much in the same time frame. I am not saying it should take precedence over any other critical work (e.g., eventlet removal), I think now is the time to scope the work and plan to meet the 2027/2028 deadline.
• OpenStack customers planning to run it well into the 2030s are asking about the plans for PQC support. And new customers considering OpenStack are asking about PQC support plans. Either we have an answer, a roadmap, or OpenStack will not be part of the discussion, at some point (ask me how I know :-).

Regards,

JP