Hello,
I was trying to replace our own implementation of CTR_DRBG in GnuTLS[1] with the one provided by Nettle. It is, however, blocked as it is currently not possible to reseed an already initialized instance without re-initializing it, which is needed for FIPS 140-3 compliance.
I would suggest either:
- making drbg_ctr_aes256_output internally do reseeding based on the interval defined in SP800 90A - exposing drbg_ctr_aes256_update as a public function, so applications (e.g., GnuTLS) can implement the reseeding logic
I've filed an MR for the latter[2]. Could you take a look?
Footnotes: [1] https://gitlab.com/gnutls/gnutls/-/blob/master/lib/nettle/int/drbg-aes.c?ref...
[2] https://git.lysator.liu.se/nettle/nettle/-/merge_requests/69
Regards,
Daiki Ueno ueno@gnu.org writes:
I was trying to replace our own implementation of CTR_DRBG in GnuTLS[1] with the one provided by Nettle.
What is the GnuTLS usecase? I got the impression from Simon that drbg isn't very good and that use should be rather discouraged. So I'm a bit surprised TLS depends on it.
I've filed an MR for the latter[2]. Could you take a look?
The code change looks very reasonable. It needs a doc update, not sure if it also deserves any additional tests.
Regards, /Niels
Niels Möller nisse@lysator.liu.se writes:
Daiki Ueno ueno@gnu.org writes:
I was trying to replace our own implementation of CTR_DRBG in GnuTLS[1] with the one provided by Nettle.
What is the GnuTLS usecase? I got the impression from Simon that drbg isn't very good and that use should be rather discouraged. So I'm a bit surprised TLS depends on it.
This is used for FIPS 140-3 certification purposes, where we need to use one of the approved DRBG in the same cryptographic module to be certified with necessary requirements met, e.g., reseeding, power-on self-tests, etc. In non-FIPS mode, we just use the system RNG with ChaCha20, which should be faster.
I've filed an MR for the latter[2]. Could you take a look?
The code change looks very reasonable. It needs a doc update, not sure if it also deserves any additional tests.
I've updated the documentation. Given that the code is already exercised through drbg_ctr_aes256_init and drbg_ctr_aes256_random, I don't see the need of dedicated tests, though it might make sense to extend the existing tests with the ACVP test vectors we use[1].
Regards,
Footnotes: [1] https://gitlab.com/gnutls/gnutls/-/blob/master/lib/nettle/int/drbg-aes-self-...
Daiki Ueno ueno@gnu.org writes:
The code change looks very reasonable. It needs a doc update, not sure if it also deserves any additional tests.
I've updated the documentation.
I've merged to master-updates, will merge to master as soon as CI is happy (I had to fix a texinfo error).
Given that the code is already exercised through drbg_ctr_aes256_init and drbg_ctr_aes256_random, I don't see the need of dedicated tests, though it might make sense to extend the existing tests with the ACVP test vectors we use[1].
It looks like that test uses a personalization string, so maybe not a great fit (even though it should be possiblt to have the testcode implement that personalization; I haven't look into how that is defined).
Regards, /Niels
nettle-bugs@lists.lysator.liu.se
-
Daiki Ueno -
Niels Möller