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

My understanding of PQC in FIPS is that ACVP testing for ML-KEM and ML-DSA is available already, and the ACVP docs also already mention SLH-DSA and LMS. Atsec has obtained CAVP certificates for PQC already, so it seems like you can FIPS-certify PQC now if you want.

Can you point me to a source for your statement on FIPS PQC timelines?

Due to severe usability issues with LMS, I strongly encourage not to include it all, or have it off by default. If it is on by default, may distributions are likely to turn it off on security grounds. Or only offer it as opt-in / as part of separate builds. As usage of LMS is likely have no practical need. It is sort of dead on arrival.

Oracle has discussed internally and would like to see support for PQC in the following order of priority: ML-KEM, ML-DSA, LMS Verify, SLH-DSA.

 
Regarding the order of SLH-DSA & LMS Verify:

• SLH-DSA does not have a known use case within Oracle currently, but Oracle would still like it included if possible.

• Some companies have been following NSA and adding HSS/LMS for signing in HSMs, like Luna https://cpl.thalesgroup.com/sites/default/files/content/solution_briefs/field_document/2023-08/thales-luna-post-quantum-crypto-functionality-module-sb.pdf. The algorithm for verification needs to be available in the crypto provider used in the firmware.

Oracle is optimistic that both LMS verify and SLH-DSA can be included for the following reasons:

• Shane Lontis from Oracle has been responsible for dev work for both of these algorithms so Oracle has insight into the status of this work. 

• LMS verify development work is complete and has high testing coverage. The work has had 1 review and only requires 1 more review to complete.

• Shane Lontis and Paul Dale are currently working on ML-DSA & SLH-DSA.

The 1 outstanding LMS verify review must be from someone other than Shane or Paul, which means it should not affect their progress on SLH-DSA.

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

As Chris points out, that choice is not a given. So I think the question is simply whether to include LMS Verify since it is nearly done.

>> Alicja Kario: ...opposed to inclusion of signing code of LMS:

>> software implementation of LMS cannot be used safely.

>> Dmitry Belyavsky: ...not interested in LMS signing (and considers it totally unsafe)

I have concerns about LMS signing as well, but that's not what this is about. We want to know whether to include LMS verification (no signing).

This is an opportunity to include LMS Verify in the next FIPS validation (FIPS covers verify but not signing in software) and CNSA 2.0 includes it, so why not add it?

This is an opportunity to include LMS Verify in the next FIPS validation (FIPS covers verify but not signing in software) and CNSA 2.0 includes it, so why not add it?

Because next to nobody will be able to generate those signatures. Having code that's there but unused is just increasing the attack surface for no benefit. We don't trust NSA's insistence on LMS, XMSS and explicitly excluding SLH-DSA. Same for their exclusion of HSS and XMSSMT.

Pretty use case dependent. Lower in the stack LMS is being used today by HSM vendors for firmware/image signing and on-prem equipment vendors. Obviously this is not a use case for everyone. LMS signature verification does have value IMO. For other use cases further up the stack, sure, LMS is not ideal nor even a good choice. I'll leave the crypto discussion to cryptographers (that's not me). :)