Zoltan Fridrich zfridric@redhat.com writes:
- The slh_dsa_shake_128s_root seems to serve the same purpose as the
slh_keygen_internal function in the spec.
I think that's right.
*Other than for testing purposes, the interfaces for key generation and signature generationspecified in this section should not be made available to applications, as any random valuesrequired for key generation and signature generation shall be generated by the cryptographicmodule*". So perhaps slh_dsa_shake_128s_root should not be exposed as a public API function.
I'm not that concerned with those requirements, Nettle doesn't try to be a "cryptographic module" in the fips sense. And it doesn't have any way to generate random bits "internally", it has to rely on the randomness function passed by the application (and today, I think a function just reading /dev/random is the reasonable choice in most cases).
That said, I'm not sure there's a good usecase for exposing this function. I would have been happier if keys had been designed so that private key is any random string, and public key derived from the private key in a fully determinsitic way. (It's not obvious to me why the spec says that the public_seed must be independently generated, rather than just computed based on hashing of the private key, but I think I should conform to the spec on this).
Otherwise, the API looks good. Eventually there should also be the pre-hash variants for sign and verify present in the API.
- I think first there should be at least one fast and short option
available.
Makes sense, I'm working on adding slh-dsa-shake-128f. Current speed on my laptop:
$ ./examples/hogweed-benchmark slh-dsa-shake name size sign/s verify/s slh-dsa-shake-s 128 0.76 992.98 slh-dsa-shake-f 128 20.19 337.95
$ ./examples/hogweed-benchmark eddsa name size sign/s verify/s eddsa 255 24990.3 6626.5 eddsa 448 6645.6 1797.3
So for verify operations (consider signed firmware updates in some embedded system expected to operate for decades), it's only about one order of magnitude slower than classic signatures.
Another question: All other public key algorithms are in libhogweed, and depend on GMP bignum functions. But the motivation for the nettle/hogweed split was to avoid a runtime shared library dependency on GMP for applications that don't use any algorithms based on bignums. And therefore, it seems slh-dsa belongs in libnettle, not libhogweed. Do you agree?
Regards, /Niels