[PATCH v12 1/9] stdlib: Add arc4random, arc4random_buf, and arc4random_uniform (BZ #4417)
Adhemerval Zanella Netto
adhemerval.zanella@linaro.org
Fri Jul 22 17:00:30 GMT 2022
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?
More information about the Libc-alpha
mailing list