OpenSSL Communities
Thu 16 Jan 2025 3:00PM

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

JJ Jeff Johnson Public Seen by 52

All, the BAC has been asked to reach out to the community and see what the thoughts were around including LMS verification in the OpenSSL3.5 release. This release is scheduled for April 2025. It appears the dev is mostly done. However delivering this could delay the inclusion of SLH-DSA in the OpenSSL3.5 release. So as Tim Hudson put it... "So the question really is would half-of-LMS be a higher priority to all of SLH-DSA for OpenSSL-3.5?"

What say you all? If I knew how to do a poll here I would but I haven't a lot of experience with this tool. I will learn :). For now it will be manual.

Additionally I would like to start regular meetings for the large business community. Working thru what that might look like now. Stay tuned. Thanks!

MK

Matthias Kraft Fri 17 Jan 2025 7:40AM

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

AK

Alicja Kario Fri 17 Jan 2025 1:14PM

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.

DB

Dmitry Belyavsky Fri 17 Jan 2025 1:18PM

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

CL

Clemens Lang Fri 17 Jan 2025 1:22PM

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.

TC

Tim Chevalier Fri 17 Jan 2025 3:15PM

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

GW

George Wilson Fri 17 Jan 2025 4:52PM

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