On Mon, Aug 01, 2022 at 02:07:53AM +0000, Elliott, Robert (Servers) wrote: > Since chrony is using a library (e.g., gnutls) for cryptography, perhaps > it should use that library's random function as well rather than use > a function from glibc or go directly to the /dev/urandom file. > Let the library figure out the best technique to use.
The chronyc keygen command is supposed to work even when not built with the SECHASH or NTS feature, i.e. not using a crypto library, so there has to be some support for generating keys. AFAIK there is nothing wrong with using /dev/urandom for generating keys and the crypto libraries use it for seeding their own (fast) random generators. In any case, it is documented in the chronyd and chronyc man pages. > Relying on one library would help eventual FIPS validation efforts - > it would be easier to demonstrate that chrony is also FIPS compliant > if it relies on a library that is in FIPS mode. Sounds like an unnecessary complication to me, which would need additional testing. > Red Hat recommends that at https://access.redhat.com/articles/3655361: > "In order to access a CSPRNG in an application, the use of the kernel's > getrandom() interface is recommended only when no cryptographic library > is used. When an application is already depending on one of our core > crypto libraries, we recommend using that library's provided interfaces." chronyd doesn't use getrandom() for generating keys or anything that would require a CSPRNG. In the two instances where a CSPRNG is needed, it's always /dev/urandom and that is easy to verify. -- Miroslav Lichvar -- To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
