SLH-DSA parameter sets

[David A. Cooper]

Hello all,

Draft FIPS 205 specifies 12 parameter sets for SLH-DSA. In addition, NIST currently plans to develop a Special Publication that will specify additional SLH-DSA parameter sets -- parameter sets that have lower limits on the number of signatures that can safely be generated.

During the public comment period, NIST received comments about the parameter sets in Draft FIPS 205, mostly recommending that the number of approved parameter sets be reduced. Some of the comments are copied below. I have also noticed at least one external discussion on this topic: https://mailarchive.ietf.org/arch/browse/pqc/?q=SLH-DSA%20parameter%20sets%20cause%20me%20anxiety.

Based on these comments, NIST is considering reducing the number of parameter sets in FIPS 205, and so seeks additional input on which of the parameter sets in Draft FIPS 205 should be included in the final version of FIPS 205. We would like to hear both from people who believe the number of parameter sets should be reduced and people who believe that all 12 parameter sets should remain.

Thank you,

David Cooper
NIST PQC

---

NSA

Having 12 different parameter sets is not conducive to inter-operability and may cause practical usage issues if different groups implement different versions. We suggest NIST chooses a smaller number of options. For instance, NIST should select either the small signature parameters or the fast signature parameters, but not both.

John Preuß Mattsson

“The 12 parameter sets included in Table 1 were designed to meet certain security strength categories defined by NIST in its original Call for Proposals [21] with respect to existential unforgeability under chosen message attack (EUF - CMA)” .

We think this is a good selection of parameters. Sections 10.1, 10.2, and 10.3 provide a clear illustration of how much easier it is to work with SHAKE instead of SHA2. The SHA-2 versions are downright inelegant and complexity like this often leads to specification and implementation bugs.

Cloudflare

We see one opportunity to reduce the number of variants:

• We do not see the need for both a SHAKE and a SHA2-based variants of SLH-DSA.

Panos Kampanakis

We want to suggest for NIST consider SHA-256 only for Level 1 and exclude SHA-512 for Levels 3, 5. Levels 3 and 5 should only leverage SHAKE256. SHAKE256 should still be available for Level 1. The advantage of only using SHA-256 for Level 1 allows for more resource constrained or performance demanding uses to be able to use the SHA-2 family especially for the faster and leaner Level 1 SLH-DSA parameters. Using SHAKE256 for all levels beyond that allows for SHAKEs to be used as the hash function of the future. SHAKEs should be the hashes of choice due to their superiority in all signature schemes and such an approach enables that future.

[Kampanakis, Panos]

Thank you for considering this David and NIST team.

 

Speaking for myself. I would only keep

 

1. slh-dsa-128s-sha2

2. slh-dsa-128f-sha2

3. slh-dsa-128s-shake

4. slh-dsa-128f-shake

5. slh-dsa-192s-shake

6. slh-dsa-192f-shake

7. slh-dsa-256s-shake

8. slh-dsa-256f-shake

 

1 and 2 could be used by applications that need to use fast, optimized and efficient SLH-DSA, or that have not implemented SHAKEs, or have constraints in code size and speed and can’t bring in both SHA2 and SHAKE. These parameters would give them Level 1 security which is adequate for a classical and a post-quantum world for a very long time.

 

Excluding slh-dsa-192* and slh-dsa-256* avoids mandating the additional support of SHA-512 for implementations.  

 

Parameters 3-8 would be the parameters using the more modern Keeccak family with its advantages. They provide all levels of security and can be considered the SLH-DSA for the long-run where theoretically we will be seeing more SHA3/SHAKE adoption.  These parameters could be used in conjunction with other PQ schemes that only want to use the SHAKE family.

 

 

 

From: 'David A. Cooper' via pqc-forum <pqc-...@list.nist.gov>
Sent: Thursday, February 1, 2024 1:37 PM
To: pqc-forum <pqc-...@list.nist.gov>
Subject: [EXTERNAL] [pqc-forum] SLH-DSA parameter sets

 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

 

--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/a0316800-bb88-4e3a-80b4-8001c46d43a7%40nist.gov.

[Markku-Juhani O. Saarinen]

Hi All,

Some comments, form the experience of having recently implemented all 12 SLH-DSA parameter sets for a hardware Root-of-Trust (RoT) system:

- On NSA's suggestion: If forced to choose between fast and small parameter sets, I'd choose the small ("s") parameter sets. Note that the "fast" label applies to signing only; verification of "small" parameter sets is roughly 2x faster, while the signature is less than half the size. I'd expect typical applications of SLH-DSA to be such that there is more verification than signing (e.g. firmware signatures.)

By the way, it may come as a surprise that SLH-DSA is *the* fastest algorithm for signature verification on some hardware platforms. Signature verification with the SLH-DSA-SHAKE-128s parameter set is currently 178,006 cycles (0.593ms @ 300 MHz) on this  RoT. This platform has a single Keccak unit of 57.6 kGE with dedicated hardware optimizations such as padding automation and Winternitz chain iteration. It is very difficult (if not impossible) to implement Elliptic Curve or Dilithium signature verification with latency, hardware footprint, and energy profile this small. (A more detailed SLH-DSA hardware study has been submitted for publication and the implementation will be open-sourced.)

- If forced to choose between SHA2 or SHAKE, I'd choose SHAKE anytime. SHA2 variants ended up being about 50% slower overall on the RoT when compared to SHAKE. While a "Category 1" unit with SHA2-256 (only) is smaller (36.9 kGE) than SHAKE (56.7 kGE), Category 3 and 5 parameter sets additionally require SHA2-512 which makes the overall unit larger (95.0 kGE) than the SHAKE unit (the SHAKE unit supports all security levels consistently.) Additionally,  if SCA countermeasures are required for signing, securing Keccak/SHAKE is much easier.

Hence I agree with  Panos also from hardware viewpoint that it is sensible to consider having only the two Category 1 variants of the SLH-DSA-SHA2 variants included, and all six variants of SLH-DSA-SHAKE.

I also agree with J. Mattsson that the SHA2 variants are relatively complex and inelegant, requiring HMAC and MGF1 wrappers for some components -- although these are not time-critical components.

Cheers,
-markku

[Andreas Hülsing]

Dear all,

Speaking for myself I would like to highlight the following: When specifying the XMSS RFC, we were told to include less parameters, so we did. Afterwards, the LMS RFC appeared with more parameter sets (and even more are getting added). I have heard several times that people chose LMS over XMSS as "it is more flexible in terms of parameters" and offers more choices. Given that the difference of code for different parameters of hash-based signatures is usually quite limited (often really limited to the parameter specification) I would strongly suggest to rethink this. Limiting the parameters to only the simple parameters was already quite a constraint. 

Cheers,

Andreas 

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/aeafe690-0e83-4513-ab0c-9721dad9b3f0n%40list.nist.gov.

[Christine Cloostermans]

Hi all,

Some more thoughts from the constrained embedded device perspective. On the whole we do not see many issues with having flexibility in parameter sets. As Andreas mentioned, for the code it does not matter a lot. However, if the reduction is desired, we would add the following thoughts:

- We strongly advocate for keeping the SHA-2 parameter sets. Many embedded devices which are already deployed in the field will have HW acceleration on board for SHA-2, but not for SHAKE. With the motivation of PQC implementations (not only SLH-DSA, but also ML-KEM and ML-DSA) more devices will likely be designed with SHAKE support built in. However, this transition period can easily span 10 years. Keeping the SHA-2 option would ease the migration of current embedded devices to PQC. 

- We also advocate for not removing the category 3/5 SHA-2 option. We do see high-security requirements (level 5) for constrained SHA-2-enabled devices. Cutting these parameter sets just for the sake of having less parameter sets does not make sense in our opinion. It keeps the complexity while reducing the usability of SLH-DSA.

- We agree with Markku that given the choice between small (“s”) and fast (“f”), we would also prefer small. For most of our use cases (secure boot, firmware update) only signature verification occurs on device. Additionally, for embedded devices past experience has shown that for PQC implementations size is usually more prohibitive than performance. 

Cheers on behalf of the NXP PQC team,

Christine

Op do 1 feb 2024 om 21:55 schreef Andreas Hülsing <ie...@huelsing.net>:

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/c2a13d17-fa94-461c-8dee-3e969619d388%40huelsing.net.

[John Mattsson]

Hi,

 

- If you decrease the number of parameter sets, we (Ericsson) largely agree with Markku. SHAKE is preferable over SHA-2 and ("s") is preferable over ("f"). For our use cases of SLH-DSA, verification speeds are much more relevant than signing speeds. We would like NIST to keep at least the following three:

 

slh-dsa-128s-shake

slh-dsa-192s-shake

slh-dsa-256s-shake

 

- That the "fast" variants have much slower verification than the "small" variants is likely surprising to many. I think NIST should describe this clearly in FIPS 205.

 

- Before discussing cutting away existing parameter sets and replacing them with additional parameter sets It would be good to know NIST’s opinion on private key export. Will parameter sets ‘tuned’ to less than 2^64 signatures come with restrictions on private key export?

 

Cheers,

John Preuß Mattsson

 

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAHzQBQUgYAQedbGYgG8yOPt-CPW1EKHFT-nHYS88xS3%3DiU8W-w%40mail.gmail.com.

[John Mattsson]

Hi,

 

To give my view on the question I asked NIST. I think that SLH-DSA parameters tuned to less signatures than 2^64 are very different from the stateful XMSS/LMS. My understanding is that the security of XMSS and LMS drops to zero immediately when misused. The security of SLH-DSA does not drop at all until a certain number of signatures has been made and then it decreases slowly. In SP 800-208, NIST chose to forbid export of the private key, which makes XMSS/LMS impossible to use in many use cases. In the SP specifying new SLH-DSA parameters I strongly think that giving security considerations is enough.

 

Cheers,

John Preuß Mattsson

 

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/GVXPR07MB967866FA146204E986F5100789422%40GVXPR07MB9678.eurprd07.prod.outlook.com.

[Stefan Kölbl]

Hi,

We agree with others that the implementation costs for the algorithm itself to support additional parameter sets are very small in the case of SLH-DSA. However, a large set of parameters will still lead to an explosion of combinations on a higher level, e.g. in protocols or hybrid signatures. Therefore keeping the overall parameter set small is desirable. Especially, if we can already anticipate that only a very small subset of parameters will actually be used.

We don’t see much use for the “f” parameter set and it seems unlikely that they would enable specific use cases. For a comparison:
* SLH-DSA-SHA2-128s:  644,740,090 cycles for signing
* SLH-DSA-SHA2-128f:     33,651,546 cycles for signing
* Dilithium2: 333,013 cycles for signing

While signing is 20x faster for the “f” parameters, this is still 100x slower than Dilithium2 and with >2x signature size and >2x verification speed compared to the “s” parameters is unlikely to be a competitive option.

As Christine mentioned, there is a need for SHA2 instantiations as SHAKE256 adoption is still lacking. For low-end devices (and 32-bit platforms), SHA256 is still significantly faster than SHAKE256 in software as well. See for instance the benchmarks available at https://github.com/mupq/pqm4/blob/master/benchmarks.md: Verification with sphincs-sha256-128s-simple takes on average 7,165,875 cycles while sphincs-shake256-128s-simple takes on average 29,495,105 cycles.

Dropping the SHA2 instantiations completely would lead to significant friction here, especially for the 128-bit security target so we would strongly support keeping both:

* SLH-DSA-128s-SHA2
* SLH-DSA-128s-SHAKE

For higher security levels, only keeping the 256-bit variant may be an option as well to be compliant with regulations requiring 256-bit security. I’d be interested to hear about cases where a 192-bit security level is required/sufficient by standards/regulations, as this seems uncommon. The only case I’m aware of is CNSA 2.0, which requires 256-bit security basically for everything (i.e. level V Kyber/Dilithium), however for software and firmware signing with LMS/XMSS it allows (and even recommends) to use SHA-256/192 for all classification levels.

Cheers,
Stefan

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/GVXPR07MB96780C0E7D66B4EEF628751089452%40GVXPR07MB9678.eurprd07.prod.outlook.com.

[Blumenthal, Uri - 0553 - MITLL]

I agree with John’s points. 

Regards,

Uri

On Feb 7, 2024, at 04:58, 'John Mattsson' via pqc-forum <pqc-...@list.nist.gov> wrote:



Hi, To give my view on the question I asked NIST. I think that SLH-DSA parameters tuned to less signatures than 2^64 are very different from the stateful XMSS/LMS. My understanding is that the security of XMSS and LMS drops to zero immediately

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside the Laboratory.

 

ZjQcmQRYFpfptBannerEnd

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/GVXPR07MB96780C0E7D66B4EEF628751089452%40GVXPR07MB9678.eurprd07.prod.outlook.com.