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. 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. > - 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? > 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. > 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. Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list -- [email protected] To unsubscribe send an email to [email protected]
