Zoltan Fridrich <[email protected]> writes: > I would like to contribute an implementation of SLH-DSA to Nettle. > The implementation is based off of the reference sphincs+ implementation > and leancrypto slh-dsa implementation. Included tests contain test vectors > from leancrypto slh-dsa tests.
Thanks! I've now read the spec https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.205.pdf, and it looks like there are lots of parts, all rather simple. Unfortunately there are a couple of variations (besides the rather important parameter tradeoffs for security, speed, signature size), though: * Signatures can be randomized or deterministic. * Signatures can be "pure" or prehash. * One can use either shake or sha2. * Some of the sha2 variants use "compressed" addresses, I don't quite understand what's the point of that additional complication. How do these variants relate to your usecase (mainly tls?), and others'? Is there one variant that is of primary importance, which should be the first one implemented? For the api, I think it should be possble to support "pure" signatures without requiring all of the message in memory at once, using a init/update/final-style interface for sign and verify, based on the update function of the underlying hash. Is that worth while? It also looks like it should also be possible to generate (easy) and verify (more complex) signatures incrementally, which might be useful on very memory constrained devices, or for systems handling lots of signatures in parallel (since signatures can be somewhat large). Probably not important in the first iteration. I haven't yet looked closely at the code, but I have some initial questions: Does the implementation aim to be side channel silent? (According to the spec, implementations should be side channel silent *both* for signature creation and verification; in Nettle, I don't think there's any signature verify code that promises side channel silence). Is the implementation optimized for speed? I see some potential high-level optimizations of the algorithms as described in the spec, like producing merkle root hashes, and maybe auth paths too, based on sequential processing of the leaves, rather than recursion. As well as potential microoptimizations. 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]
