Re: getentropy() vs. getrandom() vs. arc4random()

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

> On 16 Jun 2022, at 10:27, Yann Droneaud <ydroneaud@opteya.com> wrote:
> 
> Hi,
> 
> Le 16/06/2022 à 19:12, Fernando Gont a écrit :
>> 
>> On 15/6/22 15:00, Adhemerval Zanella wrote:
>> [....]
>>>> Is this actually the case?
>>> 
>>> On glibc, getentropy and getrandom both end calling getrandom syscall
>>> although with different flags. The getentropy calls getrandom without
>>> any flag which in turn get entropy from /dev/urandom. The getrandom
>>> function allows us to specify which source you use through
>>> GRND_RANDOM flag.
>>> 
>>> Also, getentropy current has a hard limit of maximum of 256 bytes and
>>> it is not defined a cancelation entrypoint (so pthread_cancel does
>>> not act upon it).
>>> 
>>> So both functions drawn entropy direct from the kernel and with
>>> recent Linux random number development to unify both random and
>>> urandom the difference might ended up with just getentropy being a
>>> cancellation entrypoint.
>> 
>> One question here:
>> If getentropy() ends up calling getrandom() to read from /dev/urandom, my understanding is that it would never block. Is that correct?
>> 
> 
> getrandom() syscall will block until the kernel CSPRNG is fully initialized (gathered enough entropy) after system boot.
> 
> After that, it will never block and behave like /dev/urandom. The blocking behavior is mostly a problem for PID 1.

Yes, and getrandom does not *read* /dev/urandom in the sense that it uses a file
descriptor to do so (I think it is worth to make it clear).

And I think kernel is trying to improve this on recent releases, although I do not
know the current status.

> 
> 
>> However, the manpage for getentropy(3) says:
>>        A call to getentropy() may block if the system has just booted
>>        and the kernel has not yet collected enough randomness to
>>        initialize the entropy pool.  In this case, getentropy() will
>>        keep blocking even if a signal is handled, and will return only
>>        once the entropy pool has been initialized.
>> 
>> Am I missing something?
>> 
>> 
>> Aside, from what I read in the manual pages, getrandom()/getentropy() e.g. does not result in a uniform distribution. So, in other words, one can not really use them to comply with the requirements in RFC4086 (i.e., as a cryptographically secure PRNG), but rather only use it as a building block to build such a CSPRNG?
>> 
> 
> Could you provide the part that state the output is not uniformly distributed ?

Indeed it is also new to me.