On Wed, 2025-01-29 at 12:08 +0100, Niels Möller wrote: > Zoltan Fridrich <[email protected]> writes: > > > > Another naming question, should it be dsa_slh_shake128, or maybe > > > dsa_slh128_shake ? > > > > We could stick to the spec param names like slh_dsa_shake_128s. Also do you > > prefer slh_dsa or dsa_slh prefix? > > I was a bit careless, it seems. The spec name slh_dsa_shake_128s looks > reasonable, and we could stay consistent with that. > > Simon Josefsson <[email protected]> writes: > > > It would be nice to get naming right... > > I agree, thanks for helping out. > > > - The DSA-SLH specification aren't final, are they? NIST is known to > > make last minute incompatible changes that can complicate naming, or > > make a small change in five years that modify the algorithm. > > According to https://csrc.nist.gov/pubs/fips/205/final, the version > published 2024-08-13 is final. And it includes some changes (context > string, domain-separation stuff) which, as I have understood it, makes > the spec incompatible with the earlier SPHINCS+ proposal. > > I would expect that the NIST version is the one that will be deployed in > practice. For that reason, I'd lean towards using the NIST names.
This is correct, SPHINCS+ is just an historical artifact that nobody should use, let alone implement, at this point. And given SLH-DSA is not interoperable with SPHINCS+ it makes no sense to use sphincs derived naming. > > I would also lean towards initially not supporting non-empty context string. > > > - Using "s" (for "small") and "f" (for "fast") variants is in common > > use. > > Makes sense, I think we should have that in our naming. I strongly suggest looking around at what others do which is mainly to try to stay close to the naming suggested via FIPS205. Specifically in section 11 of FIPS 205 there is a table of parameter sets that defines these names: SLH-DSA-SHA2-128s SLH-DSA-SHAKE-128s SLH-DSA-SHA2-128f SLH-DSA-SHAKE-128f SLH-DSA-SHA2-192s SLH-DSA-SHAKE-192s SLH-DSA-SHA2-192f SLH-DSA-SHAKE-192f SLH-DSA-SHA2-256s SLH-DSA-SHAKE-256s SLH-DSA-SHA2-256f SLH-DSA-SHAKE-256f I think it is ok to avoid capitalization and convert hyphen to dash, but otherwise I recommend following exactly this nomenclature to avoid confusion in users. > > - Round 2 submission of SPHINCS+ introduced the variants "simple" and > > "robust" which has consequences for naming. > > Those are new to me (I have only read the NIST spec, I haven't followed > along in the process leading up to that). > > Which of those variants made it into the NIST spec? Is there a short > explanation for when one would want one or the other? Please follow just FIPS 205, we do not need any more "variants" or complexity really, SLH is already too complex in the number of choices as it is. > > > Using 'sha2' and 'sha3' seems clearer than including hash size like > > 'shake256' or 'sha256'. > > I agree the hash size should be attached to the signature algorithm > rather than to the underlying hash algorithm. But I think "shake" rather > than "sha3" seems reasonably clear too. SHAKE is not SHA3, using SHA3 would be incorrect and confusing. > > Expanding 'small', 'fast, 'simple' and 'robust' may avoid some > > confusion. I've made the mistake of confusing 'small' with 'simple' > > when I used 's' myself. > > Right, if we're going to have them all, then "s" as abbreviation gets > confusing. Only the small and fast variants are relevant, the others are just historic and should not be implemented now. HTH, Simo. -- Simo Sorce Distinguished Engineer RHEL Crypto Team Red Hat, Inc _______________________________________________ nettle-bugs mailing list -- [email protected] To unsubscribe send an email to [email protected]
