[PATCH v10 9/9] manual: Add documentation for arc4random functions

[Adhemerval Zanella Netto]

On 19/07/22 14:13, Cristian Rodríguez wrote:
> On Mon, Jul 18, 2022 at 10:49 AM Florian Weimer <fweimer@redhat.com> wrote:
>>
>> * Cristian Rodríguez:
>>
>>>> I think it's more important to make sure that unmodified glibc can be
>>>> used in a certified environment.  Our implementation is not certifiable
>>>> because it's not using an approved algorithm.  The OpenBSD
>>>> implementation has the same issue: in a certified environment, it either
>>>> has not be documented as not cryptographically secure, or it has to be
>>>> implemented on top of an approved algorithm.
>>
>>> In that case the linux kernel is also non certified.. whatever..maybe
>>> omit the paragraph all together.
>>
>> These certified configurations already need a patched/custom kernel.
>> But we don't want to add a patched glibc as an additional burden.
>>
>> Thanks,
>> Florian
> 
> Then why not add a tunable where the api just calls getrandom y you
> already have a patched kernel?

Why not just call getrandom then? If you really need a CSPRNG best course
of action is actually to ask kernel for more entropy.  I don't see much
gain in adding a tunable where glibc *already* provides a API to access
such interface (worse case the program will need to /dev/urandom, but it
also means the kernel is old).

> Come on, a tiny amount of users need to comply with FIPS.. one could
> also want to use DJB fast key erasure RNG with AES-Ni.. but again it
> won't comply .. nothing sane does.