SLH-DSA: integrate final standard

[SWilson4]

In line with FIPS 205.

We have support for Round 3 SPHINCS+, but nothing more recent. Our current upstream source is https://github.com/sphincs/sphincsplus via PQClean, so we should find out their plans for updates.

Tagging @bwesterb as a significant upstream contributor: are there plans to bring the implementation in sync with the final standard?

[bwesterb]

Tagging @bwesterb as a significant upstream contributor: are there plans to bring the implementation in sync with the final standard?

Yes, we will. I'm prioritising Kyber -> ML-KEM myself as we have that deployed quite widely. I'll ping the rest of the team.

[psheer-spirent]

Hello,

According to Commit 36f3994 , liboqs is compliant with SPHINCS+ 3.1, June 10, 2022.

Now the FIPS 205 pdf reads that Sphinx+ 3.1 is a superset of SLH-DSA.

So it looks like, except for changing the cipher user-friendly names, liboqs is already compliant with FIPS 205.

Can anyone help here? Does liboqs now fully implement a binary compatible FIPS 205?

Thank you and kind regards!

Paul

[SWilson4]

Hi, @psheer-spirent. I do agree that Appendix A of FIPS 205 makes it sound like SLH-DSA and SPHINCS+ 3.1 should be the same on the parameter sets we support. However, I suspect that in order to implement FIPS 205, we would need to add the "external" API, which appears to add domain separation and a context string. We need to make similar changes to support the FIPS 204 final version of ML-DSA.

[psheer-spirent]

Hi, @psheer-spirent. I do agree that ....

Thanks @SWilson4 for that clarification.

Do you know if oqs-provider+liboqs intends full compliance with FIPS-203, FIPS-204, and FIPS-205?
I had assumed that 203 and 204 were already supported since the README.md for oqs-provider states under version 0.6.0, "First availability of standardized PQ algorithms FIPS.203, FIPS.204".

Is anyone right now working toward full compliance?

Kind regards,

Paul

[baentsch]

Good question, @psheer-spirent but not totally simple to answer: The answer to the best of my knowledge is "Most likely, Yes": The key challenge is that the OQS project does not do algorithm development or maintenance itself, so is completely dependent on the upstreams for code (incl. its properties, like adherence to standards or safety and security properties) and thus cannot make any guarantees.

The phrase you quote above indeed was worded too aggressively: At the time of that release, NIST didn't complete standardization, it only announced "initial public drafts". It was those that the software was in line with at the time. Mea culpa -- I've become much more cautious in phrasing things since then, e.g., also adding explicitly the usage warning from liboqs and not just linking to it. We recognize there's substantial amounts of effort still required to make all of this ready for "prime time" (even after all upstream code has been integrated).

The state of affairs on FIPS 205 is captured in this issue and OQS welcomes contributions to resolve the issue. FIPS 204 is being worked on by the upstream contributor in #1919.

[psheer-spirent]

Thanks for that explanation. I appreciate your time.

Kind regards.

[dstebila]

With the SLH-DSA work in OpenSSL getting closer to landing in OpenSSL, I guess this raises the question of whether liboqs should also have its own implementation of SLH-DSA, or whether we just wrap that (when building against OpenSSL). @baentsch what do you think?

If we do pull in our own SLH-DSA implementation, then the question is who intends to do that work and maintain it. @ashman-p you worked on the stateless hash-based signatures, do you have interests for SLH-DSA as well?

[cothan]

If @ashman-p is busy, I’d be interested in taking on that task. Let me know how I can help.

[baentsch]

@baentsch what do you think?

I think we already have precedence for that: Also in (oqs-)boringssl the existing upstream code (ML-KEM in that case) gets priority, right?

IMO from a quality, support and maintenance perspective, using/wrapping OpenSSL code makes sense (also there is precedence with OpenSSL SHA3/XOF use). That said, openssl/openssl#25882 most likely won't be back-ported to OpenSSL < 3.5 releases and further may not be everything that the research community wants from SLH-DSA -- which is the community OQS is meant to support primarily, right? That might argue for an OpenSSL-independent implementation.

But then again, if there is no-one dedicated to support the OQS SLH-DSA upstream code base in the long run (?), my recommendation very clearly would be to stop OQS activities around that algorithm based on the same argument I made time and again: OQS cannot provide stronger promises (regarding quality, interoperability, support, etc.) than the upstreams it integrates.