Re: getrandom vs. crypto/gc-random

[Bruno Haible]

Paul Eggert wrote:
> The remaining issue is "partial overlap with crypto/gc-random".

Yes. It has three aspects:

1) The list of random devices, determined through gc-random.m4.

> To fix that, I
> am thinking that getrandom should remove its dependency on crypto/gc-random, 
> and
> should simply use "/dev/urandom" for the nonce device without worrying about
> whether crypto/gc-random would define NAME_OF_NONCE_DEVICE to "/dev/urandom".
> This should work on all current porting targets and should simplify 
> maintenance
> by lessening dependencies on the crypto/gc-random module, which pulls in 
> several
> other modules that some packages won't want to bother with.

I agree. In my testing yesterday, I found that /dev/random and /dev/urandom are
present in all modern versions of operating systems, except native Windows.
I tested:
  Linux Fedora 1       OK
  Linux Ubuntu 16.04   OK
  Linux Ubuntu 18.04   OK
  Linux Ubuntu 20.04   OK
  Linux Alpine 3.9     OK
  Hurd 2019            OK
  GNU/kFreeBSD         OK
  Mac OS X 10.5        OK
  Mac OS X 10.13       OK
  FreeBSD 11           OK
  FreeBSD 12           OK
  NetBSD 7.0           OK
  NetBSD 9.0           OK
  OpenBSD 6.5          OK
  AIX 7.1              OK
  Solaris 10           OK
  Solaris 11.0         OK
  Solaris 11.3         OK
  Solaris 11.4         OK
  Solaris OpenIndiana  OK
  Haiku                OK
  Cygwin               OK
  Minix 3.3            OK

Seeing this, the configure options --enable-random-device,
--enable-pseudo-random-device, --enable-nonce-device are not needed any more
- neither for gc-gnulib nor for getrandom. I won't remove them from gc-random.m4
(since that is Simon's responsibility), but I agree with you that for getrandom
we can use the two de-facto standard device names.

2) The native Windows code. For getrandom one will need a use of CryptGenRandom.
But refactoring this code in a way that makes it reusable by getrandom is more
effect than it's worth (because in gc-gnulib.c the code wants a failure already
in gc_init if the crypto context cannot be allocated, whereas for getrandom
we will just have getrandom fail).

3) There is the question whether getrandom() should be based on module
crypto/gc-random. That is, whether the configure script should accept an
option --with-libgcrypt, in order to use libgcrypt when available.
I think the answer is "no", for two reasons:
  * Would we want to override the glibc function getrandom() with an
    implementation that requires an external library? Most likely no.
  * I think libgcrypt is for programs that have strong cryptographic
    needs, such as gpg or ssh-keygen. For most other programs, the system-
    provided /dev/random should be enough.
    As the unit test is showing, /dev/random does not have the highest quality
    of random numbers (at least, it does not block when you ask for 100000
    random bytes) on
      Hurd, Mac OS X, FreeBSD, OpenBSD, AIX, Minix, Haiku,
    but this quality-of-implementation issue should be ignorable for things
    like https. libgcrypt is accumulating the entropy through subprocesses,
    which is likely overkill for a simple application like 'wget' or 'ssh'.

CCing Simon, because he may enlighten us on this.

Bruno