Should LMS Verify be included in OpenSSL 3.5 release scheduled for April?

Hi Jeff,

I don't think the availability of LMS is so urgent, that half of an implementation is better than the full scope implementation. As it is part of the SP 800-208 recommendation it needs to be available eventually, however.
From my perspective an LTS version would have much higher priority, as we need to support the shipped OpenSSL versions for multiple years and the current LTS version is nearing its public end of support date already.

Just my 2 cents ...

-- Matthias

I'm against inclusion of LMS. It's an algorithm that next to nobody will be able to deploy securely.
I've completely opposed to inclusion of signing code of LMS: software implementation of LMS cannot be used safely.
SLH-DSA is far more useful with none of the pitfalls of LMS.

Red Hat is much more interested in SLH-DSA and not interested in LMS signing (and considers it totally unsafe)

We'd definitely prefer availability of SLH-DSA over LMS verification. We're looking at how to sign software packages in the future, and the current choices are essentially:

• ML-DSA — reasonably small and fast, but new math

• SLH-DSA — larger and slower, but based on hashes, which we understand very well

• LMS or XMSS — can catastrophically fail if the state of the private key is not carefully managed, something that should probably only be done in hardware (and the entire backup and restore discussion with NIST in the Cryptographic Module User Forum shows that even then, there will be possible problems).

CNSA 2.0 forces us to chose from (ML-DSA, LMS, XMSS), but we'd rather not rely on new math for software package signatures only, and the pitfalls of LMS and XMSS sound scary. We'd prefer being able to use both ML-DSA and SLH-DSA.

Given a choice between one or the other, I would prefer to see SLH-DSA.

We also vastly prefer ML-DSA and SLH-DSA over LMS.

I'm one of the three people working full time on PQC for OpenSSL 3.5, the others being Shane Lontis (Oracle) and Viktor Dukhovni (OpenSSL). Neither Shane nor I believe that LMS's inclusion will materially impact SLH-DSA's. The LMS work is essentially complete, the remaining effort is in reviewing which can not be done by us (so it's not taking effort from the other algorithms). Review feedback might create more work, but it will be relatively minor in all likelihood.

Some notes:

• OpenSSL 3.5 is slated to be the next LTS version.

• ML-DSA is the current top priority for us.

• This proposal is only about LMS verify.

• Verify is the only part of LMS that can be FIPS validated for software modules.

• As noted several times, LMS signing has lots of pitfalls, this is not being proposed here.

CNSA 2.0 is very forward looking. At the time of publication, and still, majority of software / hardware / firmware have no support for things it demands. Thus any amount of time here or there, will not have any material impact.

In the now de-published first version of the CNSA 2.0 document, both "Web Browsers and Cloud Services" (whatever that actually means in practice, possibly key exchange using ML-KEM, possibly ML-DSA signatures in TLS, it didn't say) and "Software Signatures" had timelines that expected change in 2025. For a timeline this tight, the choices we make now matter.

The recently published FAQ document no longer lists this explicitly, or I couldn't find it. It does however say "no requirement to transition will be enforced prior to December 31, 2025". The same paragraph says "CNSSP 15 states that by January 1, 2027, all new acquisitions for NSS will be required to be CNSA 2.0 compliant unless otherwise noted."

To me, this sounds like new purchases that have to comply with CNSA will no longer be able to buy products that don't support PQC in 2027. That's not a very long time for LTS distributions, for example.

@Clemens Lang note that procurement that requires CNSA is very small, compared to FIPS. And FIPS PQC timelines are currently in draft but are for 2030+ timeframe; plus certification on top; thus realistically roughly 2031. Still not much time, but it is closer to 2 - 2.5 OS LTS cycles.