Re: [PATCH v12 1/9] stdlib: Add arc4random, arc4random_buf, and arc4random_uniform (BZ #4417)

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

On 22/07/22 12:31, Zack Weinberg via Libc-alpha wrote:
> On 2022-07-22 8:21 AM, Adhemerval Zanella via Libc-alpha wrote:
>> diff --git a/NEWS b/NEWS
>> index df882ec243..8420a65cd0 100644
>> --- a/NEWS
>> +++ b/NEWS
>> @@ -60,6 +60,10 @@ Major new features:
>>     _GNU_SOURCE macro is defined and the C++20 __cpp_char8_t feature test macro
>>     is not defined (if __cpp_char8_t is defined, then char8_t is a builtin type).
>>   +* The functions arc4random, arc4random_buf, and arc4random_uniform have been
>> +  added.  The functions use a pseudo-random number generator along with
>> +  entropy from the kernel.
>> +
> 
> I think the second sentence ought to be a little more specific than "a pseudo-random number generator", since the whole point of the arc4random* API is that it's supposed to be cryptographically strong, and since the name (incorrectly) suggests that a *known-broken* CSPRNG is in use.  Maybe something like
> 
> "These functions implement a cryptographically strong pseudo-random number generator, based on ChaCha20 and automatically seeded from kernel-provided entropy."

My understanding is we do not really want to state this scheme used is a CRNG,
since it might create an additional certification requirement (such as FIPS)
nor I have the cryptographic background to certify it follows the requirements
(although reading http://blog.cr.yp.to/20170723-random.html it does follow the
idea and it also based on already deployed implementations like openbsd).

> 
>> reseeds the internal state on every 16MB of consumed buffer
> 
> Is this sufficient to provide forward security (i.e. a state leak does not permit the attacker to reconstruct past outputs of the RNG)?
> 
> zw

I am not sure, openbsd implementation stir value was added without much comment
why the value was chosen.  Should we tune a lower bound?