[gnutls-devel] delaying the initialization of random generator

Andy Lutomirski luto at amacapital.net
Tue Nov 1 14:58:39 CET 2016


On Oct 31, 2016 2:34 AM, "Nikos Mavrogiannopoulos" <
n.mavrogiannopoulos at gmail.com> wrote:
>
> Hi,
>  Since version 3.5.3, gnutls uses the getrandom() system call on the
> kernels that it is available, replacing the /dev/urandom based
> initialization of the included RNG. However, that comes with few
> side-effects. Because getrandom() blocks prior to the linux kernel RNG
> being initialized (unlike /dev/urandom), that means that applications
> that load early on boot and link with gnutls will be blocked until
> that kernel initialization.
>
> This has been already been seen in VMs, on the cases linked by [0]. A
> work-around that can be applied to gnutls is delaying the internal RNG
> initialization to the first call of gnutls_rnd(). That will allow
> applications which do not use the RNG immediately to load faster,
> while on the other hand introduces some complexity and does not
> address the problem when for example the system is in FIPS140-2 mode
> which requires some on-library-load tests which need to call
> gnutls_rnd(). -(here I'm also worried about future additions that may
> require random numbers on library load and negate any fixes for that
> issue).

I say delay initialization for reasons that have nothing to do with
blocking: when you initialize early, the kernel is telling you that your
seed may be predictable.  So re-seeding later on is more secure.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20161101/db5f47b9/attachment-0001.html>


More information about the Gnutls-devel mailing list