PQC: SLH-DSA

[FAlbertDev]

PQC: SLH-DSA

Similar to PRs #3893 and #4270, this PR integrates the SLH-DSA (FIPS 205) instances into our SPHINCS⁺ implementation. The difference to the current SPHINCS⁺ round 3.1 implementation is marginal.

Module Hierarchy

I added new modules to allow users to activate only the final SLH-DSA instances. Since the logic is almost the same, no new logic is added to these modules. However, I think it's quite handy for users to allow only SLH-DSA instances via modules (for example, using a policy).

Future Work

I already prepared most of the logic necessary for the support of contexts and the pre-hashed instances. We are currently working on an improved API for the creation of signers, which will provide us with the API necessary for supporting the aforementioned features (see #4318). We do not expect this improved API available with Botan 3.6.0 so (non-empty) contexts and prehashed instances are postponed until then.

Also, currently, all SLH-DSA-related files are still named sphincsplus or sp_*. The same goes for the class and method names. I want to move this refactoring work into a follow-up PR since it would make reviewing this one very difficult.

SLH-DSA Specification Release - TODOs

• X.509
  • Exchange IPD with SLH-DSA OIDs
  • Read through the IETF draft and validate that our X.509 implementation handles SLH-DSA keys correctly
• Check (and possibly adopt) SLH-DSA test vectors
  • ACVP Tests: #1, #2, #3 We generated our own KATS using py-acvp-pqc since the ACVP tests are not compatible with our API.
• Go through FIPS 205 again and see if all validations are implemented (add tests)
• Implement PrehashSLH-DSA → PrehashSLH-DSA will be addressed in a future PR (probably for Botan 3.7.0)
• Implement the new "context" parameter in signing/verifying → Contexts will be addressed in a future PR (probably for Botan 3.7.0)

[FAlbertDev]

This is the only logic that differs between SPHINCS+ Round 3.1 and SLH-DSA IPD .

[randombit]

https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.205.pdf

[reneme]

Appendix A.1 mentions the introduction of HashSLH-DSA that describes an addtional domain separated signing mode when providing the actual message or a hash of the message, similar to HashML-DSA. Also here, I would suggest to implement HashSLH-DSA in a future pull request.

[randombit]

To me seems fine to implement the prehashed variant later, or not at all.

[FAlbertDev]

Update: I have now implemented SLH-DSA (without context and without prehash). However, I already prepared contexts and pre-hashes for the next iteration. Also, I did not rename the classes and files to not bloat this PR. A follow-up PR will handle this, which will not contain any logical changes.
Test vectors are still missing, but they are coming soon. Also, I still want to double-check the current implementation with the SLH-DSA spec, so we do not miss anything new.

[coveralls]

coverage: 91.254% (-0.03%) from 91.279%
when pulling e907eb7 on Rohde-Schwarz:feature/slh-dsa
into 0639e82 on randombit:master.

[FAlbertDev]

Update: Test vectors and double-checks are integrated. Next week, I will look into SLH-DSA with X.509. Otherwise, this PR should be ready for review (and side-channel analysis (@aewag)) :)

[FAlbertDev]

Thanks for your review, @reneme! I applied your review suggestions and sprinkled in some StrongTypes. Regarding the logic separation between SLH-DSA and SPHINCS+:
The total difference between both versions is about 15 lines of code. Since we cannot simply reflect this logic in the sp_hash hierarchy, I think it's not worth building an entirely new hierarchy(including new modules and classes).