Zoltan Fridrich <[email protected]> writes:
> 1. 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.
>
> 2. 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
--
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]
