[gnutls-devel] lock-free random generator

Nikos Mavrogiannopoulos n.mavrogiannopoulos at gmail.com
Tue Feb 28 09:32:56 CET 2017


On Tue, Feb 28, 2017 at 7:57 AM, Niels Möller <nisse at lysator.liu.se> wrote:
> Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com> writes:
>
>> And to answer myself, I do not think we need something complex as
>> yarrow in gnutls. Older systems may have needed it, but today we can
>> rely on /dev/urandom and getentropy() interfaces, and as such I no
>> longer it is necessary to bring that complexity to gnutls.
>
> Makes sense to me too. But do you plan any fallback for other systems? I
> guess one could require the use of some separate randomness gathering
> daemon.

No. Few releases ago I've dropped support for EGD (entropy gathering
daemon). No-one has complained so I guess such special systems most
likely use specialized libraries rather than "OS" libraries like
gnutls.

> What about MacOS and Microsoft Windows, do they have something
> comparable to /dev/random these days?

Both are supported via their native interfaces. Newer versions of
MacOS have getentropy() and older ones have /dev/urandom. Windows has
CryptGenRandom() for quite some time.

> Then I'd expect that there are quite some systems out there, where
> getting adequate randomness isn't easy. Like small embedded systems, and
> it's also unclear to me how /dev/random works on virtual machines. But
> just using a mixer like yarrow or fortuna isn't enough, since the tricky
> problem is the sourcing of the mixer.

In such small systems, even something like the (now-legacy) EGD would
be insufficient. Each of them would require some custom code, which
could be abstracted as a system call like getentropy() - especially if
that gets into posix. I don't think it makes sense to add code for
such systems without ensuring that it handles a large class of it, or
that at least it is a very common system to ignore.

regards,
Nikos



More information about the Gnutls-devel mailing list