> -----Original Message-----
> From: Miroslav Lichvar <mlich...@redhat.com>
> Sent: Thursday, July 28, 2022 9:53 AM
> To: chrony-dev@chrony.tuxfamily.org
> Subject: Re: [chrony-dev] nts_ke_server calling UTI_GetRandomBytesUrandom
>
> On Thu, Jul 28, 2022 at 02:46:38PM +0000, Elliott, Robert (Servers)
> wrote:
> > Two places call UTI_GetRandomBytesUrandom rather than
> UTI_GetRandomBytes.
> >
> > 1. nts_ke_server.c generate_key (from patch a420ed57q):
> > + UTI_GetRandomBytesUrandom(server_keys[index].key, key_length);
> > + if (!SIV_SetKey(server_keys[index].siv, server_keys[index].key,
> key_length))
> > + assert(0);
> > +
> > + UTI_GetRandomBytes(&server_keys[index].id, sizeof
> (server_keys[index].id));
> >
> > 2. client.c process_cmd_keygen (from patch 7fcf69ce):
> > + UTI_GetRandomBytesUrandom(key, length);
> >
> > Is there any reason for them to call the Urandom version directly?
>
> They generate long-term keys, i.e. need a higher-quality random
> generator. The non-Urandom version can use arc4random() which is fast,
> but not described as suitable for long term keys, at least as I
> understand it. The upcoming glibc has arc4random(), so this will be
> the case also on Linux.
I see the glibc discussion about arc4random has led to a proposal this
weekend to add a vDSO for the linux kernel's getrandom(). It'll be
interesting to see if that is accepted - Linus' initial reaction was "no".
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.
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.
(FIPS mode will require getting AES-SIV or AES-GCM-SIV approved by
NIST, and NIST will probably require the variations that are
based on 256-bit AES, so chrony will need to make some changes
for that)
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."
--
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.
