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.

[SWilson4]

Regarding the SLH-DSA / OpenSSL issue, I think that only providing the OpenSSL implementation would mark a change of direction for liboqs in that it would effectively make our non-OpenSSL build a "second-class citizen." There is currently no difference in algorithm availability when configuring the build with OQS_USE_OPENSSL=OFF. If we wrap the OpenSSL SLH-DSA implementation without also providing a non-OpenSSL alternative, then the non-OpenSSL build will lack a standardized algorithm. This, IMO, would bind liboqs (and hence the whole OQS "ecosystem") much more closely to OpenSSL than it is currently.

@ueno, I'm assuming that GnuTLS consumes a non-OpenSSL version of liboqs—could you offer any insight into the questions raised in @dstebila's comment above?

[baentsch]

Good points, @SWilson4 . I didn't mean to suggest "binding" OQS to openssl.

What would generally make sense IMO would be for OQS also making available openssl-based implementations for algorithms as and when available there, though (for the same rationale that made liboqs use openssl's RNG, AES, SHA and oqs-boringssl use boringssls ML-KEM as the prime implementation option: Better upstream support, maintenance, performance, platform-width, etc. But that may be a discussion for another venue).

So back to this issue and some thoughts/follow-on questions regarding SLH-DSA:

• For pretty much all algorithms, there is at least 1 person within the OQS team "championing" it -- and I think OQS lacks that for SLH-DSA, so right now it seems @cothan is the only person that volunteered (Thanks btw!) -- but I'm unsure how this can be successful without upstream support -- is the idea here that SLH-DSA becomes a fully OQS-only maintained algorithm? That'd be a sharp change in direction and responsibility for this project, too: Is OQS willing and able to take that on?
• Are we sure we know what the "OQS ecosystem" entails? Who within it uses/needs SLH-DSA? And of those, who must use it independently of openssl? gnutls quite probably... who else?
• And maybe even the most "heretic" question: Who needs/uses SLH-DSA at all? Could we ask such folks whether they are even part of the "OQS ecosystem"? @christianpaquin : Any insight from NCCoE? @praveksharma : Any insight from IETF hackathons? I do not recall a single question asking for SLH-DSA support (beyond our own) -- do you, @SWilson4 ?

[ueno]

Yes, gnutls would definitely benefit from the support for final standard of SLH-DSA in liboqs, as it wouldn't require hybrid construction with elliptic curves like ML-DSA in some user-cases. In the long run we will likely follow the similar approach to OpenSSL, i.e., have a native implementation in the library, in our case it will be in Nettle, so other consumers could use it, such as sequoia-pgp for PQC in OpenPGP.

[baentsch]

Thanks for the honest feedback, @ueno. nettle looks like a much more suitable library for gnutls than liboqs from a purpose, support and licensing perspective.

So my proposal response to @cothan's question

Let me know how I can help.

would then be: Adapt the current Sphincs code base via "copy_from_upstream" patches to match the "minimum requirements" of FIPS 205. Doable for you? Anyone willing to help (e.g., updating KAT tests or even ACVP ones)?

Unless anyone want to commit otherwise, I'd propose to make this manageable in the long run by adding a clear "warning" statement along the lines of "For using SLH-DSA in non-research applications, be sure to activate "OQS_USE_SLHDSA_OPENSSL" (after making this available of course :).

[ashman-p]

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?

Hi Folks,
Just catching up after taking some time-off over the holiday.
@dstebila, i would be glad to look into this. Happy to work together with @cothan on it as well.