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

[Fernando Gont <fernando@gont.com.ar>]

Hello, Adhemerval,

Thanks a lot for your response! In-line....

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?

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?

Thanks!

Regards,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1