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

[Yann Droneaud <ydroneaud@opteya.com>]

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.


> 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 ?


Regards.


-- 

Yann Droneaud

OPTEYA