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

  From: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>

---
 manual/math.texi | 46 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)
  

On Thu, Jul 14, 2022 at 7:31 AM Adhemerval Zanella via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
> From: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
>
> ---
>  manual/math.texi | 46 ++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 46 insertions(+)
>
> diff --git a/manual/math.texi b/manual/math.texi
> index 477a18b6d1..141695cc30 100644

> +Although these functions provide higher random quality than ISO, BSD, and
> +SVID functions, these still use a Pseudo-Random generator and should not
> +be used in cryptographic contexts.
>

Huh.. then we have a problem.. for all other systems that implement
arc4random.. they claim it is a CSPRNG.. this paragraph says
otherwise...
code assumes arc4random is a CSPRNG.. suitable for cryptography..
that's a pretty big difference...
  

On 14/07/22 16:40, Cristian Rodríguez wrote:
> On Thu, Jul 14, 2022 at 7:31 AM Adhemerval Zanella via Libc-alpha
> <libc-alpha@sourceware.org> wrote:
>>
>> From: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
>>
>> ---
>>  manual/math.texi | 46 ++++++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 46 insertions(+)
>>
>> diff --git a/manual/math.texi b/manual/math.texi
>> index 477a18b6d1..141695cc30 100644
> 
>> +Although these functions provide higher random quality than ISO, BSD, and
>> +SVID functions, these still use a Pseudo-Random generator and should not
>> +be used in cryptographic contexts.
>>
> 
> Huh.. then we have a problem.. for all other systems that implement
> arc4random.. they claim it is a CSPRNG.. this paragraph says
> otherwise...
> code assumes arc4random is a CSPRNG.. suitable for cryptography..
> that's a pretty big difference...

OpenBSD manual is in fact not clear [1] and FreeBSD has the same description 
as OpenBSD [2]:

"High quality 32-bit pseudo-random numbers are generated very quickly.  
On each call, a cryptographic pseudo-random number generator is used 
to generate a new result."

MacOS in the other hand does describe its implementation as CSPRNG, 
from man 'arc4random':

"These functions use a cryptographic pseudo-random number generator to 
generate high quality random bytes very quickly."

And has a specific note:

"The original version of this random number generator used the RC4
(also known as ARC4) algorithm.  In OS X 10.12 it was replaced with the
 NIST-approved AES cipher, and it may be replaced again in the future as 
cryptographic techniques advance.  A good mnemonic is “A Replacement
Call for Random”.

However for either BSD and MacOS, only the initial and subsequent rekey
are done with kernel entropy.  So similar to this proposal, the buffer
stream up to the certain limit can be derived if you know the original
kernel entropy used to initialize it.

I think in practice the approach of this patchset is similar to what
BSD and MacOS does (the only difference is we are doing per-thread
buffer instead of a global state).  I am not sure we can actually assert
this approach generates CSPRNG output, in fact neither the the BSD or 
MacOS.

[1] https://github.com/libressl-portable/openbsd/blob/master/src/lib/libc/crypt/arc4random.3
[2] https://www.freebsd.org/cgi/man.cgi?query=arc4random
  

* Cristian Rodríguez:

> On Thu, Jul 14, 2022 at 7:31 AM Adhemerval Zanella via Libc-alpha
> <libc-alpha@sourceware.org> wrote:
>>
>> From: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
>>
>> ---
>>  manual/math.texi | 46 ++++++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 46 insertions(+)
>>
>> diff --git a/manual/math.texi b/manual/math.texi
>> index 477a18b6d1..141695cc30 100644
>
>> +Although these functions provide higher random quality than ISO, BSD, and
>> +SVID functions, these still use a Pseudo-Random generator and should not
>> +be used in cryptographic contexts.
>>
>
> Huh.. then we have a problem.. for all other systems that implement
> arc4random.. they claim it is a CSPRNG.. this paragraph says
> otherwise...
> code assumes arc4random is a CSPRNG.. suitable for cryptography..
> that's a pretty big difference...

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.

Thanks,
Florian
  

On Mon, Jul 18, 2022 at 9:29 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Cristian Rodríguez:
>
> > On Thu, Jul 14, 2022 at 7:31 AM Adhemerval Zanella via Libc-alpha
> > <libc-alpha@sourceware.org> wrote:
> >>
> >> From: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
> >>
> >> ---
> >>  manual/math.texi | 46 ++++++++++++++++++++++++++++++++++++++++++++++
> >>  1 file changed, 46 insertions(+)
> >>
> >> diff --git a/manual/math.texi b/manual/math.texi
> >> index 477a18b6d1..141695cc30 100644
> >
> >> +Although these functions provide higher random quality than ISO, BSD, and
> >> +SVID functions, these still use a Pseudo-Random generator and should not
> >> +be used in cryptographic contexts.
> >>
> >
> > Huh.. then we have a problem.. for all other systems that implement
> > arc4random.. they claim it is a CSPRNG.. this paragraph says
> > otherwise...
> > code assumes arc4random is a CSPRNG.. suitable for cryptography..
> > that's a pretty big difference...
>
> 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.
  

* 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
  

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

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.
  

On Tue, Jul 19, 2022 at 1:31 PM Adhemerval Zanella Netto
<adhemerval.zanella@linaro.org> wrote:

> 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).

I also do not see the gain,but it is an alternative to the few big
guys that need toi comply with FIPS.
It appears that Im not excsactly getting my point across so I 'll try again.


-  this api originates from the BSD .
-  In the BSD land it came as a response to the standard random apis
that are of poor quality and not suitable for cryptography.
-  When RC4 was found not to be suitable for crypto, the algorithm was
changed to chacha.
-  it has never been FIPS approved
- all existing software out there including security sensitive
software does the equivalent of AC_CHECK_FUNCS(arc4random) to detect
this functionality and assumes it provides
  random data suitable for crypto, claiming the opposite in the
documentation breaks all the existing software assumptions.

IF someone really needs FIPS compliance it can now use the slow and
overly complicated FIPS RNGs provided by openSSL..
  

On 20/07/22 12:19, Cristian Rodríguez wrote:
> On Tue, Jul 19, 2022 at 1:31 PM Adhemerval Zanella Netto
> <adhemerval.zanella@linaro.org> wrote:
> 
>> 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).
> 
> I also do not see the gain,but it is an alternative to the few big
> guys that need toi comply with FIPS.
> It appears that Im not excsactly getting my point across so I 'll try again.

We have discussed it before on a previous glibc weekly call (I can recall
exactly which one), and if I recall correctly Florian has consulted with
some internal developers that work direct with FIPS certification and 
since we do not state that our implementation is cryptographic secure
there is nothing prevents it to be used along with other on FIPS
environment.

> 
> 
> -  this api originates from the BSD .
> -  In the BSD land it came as a response to the standard random apis
> that are of poor quality and not suitable for cryptography.
> -  When RC4 was found not to be suitable for crypto, the algorithm was
> changed to chacha.
> -  it has never been FIPS approved
> - all existing software out there including security sensitive
> software does the equivalent of AC_CHECK_FUNCS(arc4random) to detect
> this functionality and assumes it provides
>   random data suitable for crypto, claiming the opposite in the
> documentation breaks all the existing software assumptions.
> 
> IF someone really needs FIPS compliance it can now use the slow and
> overly complicated FIPS RNGs provided by openSSL..

Although we do some FIPS support (fips-private.h), glibc itself does not
really support FIPS certified cryptographic implementations (on fips
enabled system some crypt functions just return EPERM). AFAIK, distro that
aims to be FIPS certifies in fact disable crypt and use another library
instead (libxcrypt for instance).

I really do not think that glibc as GNU open-source project should aim or
block any addition if is is not FIPS compliant.  I don't have a strong
opinion if someone adds a proposal for check to either disable arc4random 
or call getrandom if fips_enabled_p is enable (although I personally 
prefer we just get rid of any FIPS related code within glibc).
  

* Adhemerval Zanella Netto:

> We have discussed it before on a previous glibc weekly call (I can recall
> exactly which one), and if I recall correctly Florian has consulted with
> some internal developers that work direct with FIPS certification and 
> since we do not state that our implementation is cryptographic secure
> there is nothing prevents it to be used along with other on FIPS
> environment.

And it does not create an additional certification requirement, either.

> Although we do some FIPS support (fips-private.h), glibc itself does not
> really support FIPS certified cryptographic implementations (on fips
> enabled system some crypt functions just return EPERM). AFAIK, distro that
> aims to be FIPS certifies in fact disable crypt and use another library
> instead (libxcrypt for instance).

libcrypt can be built against part of the Netscape/Network Security
Services library (the other NSS).  This way, if you have a certified
variant of NSS, libcrypt inherits the certification.

But this stopped working a while ago because NSS no longer providers
digest functions required to implement certain forms of legacy password
hashing.  However, nowadays, password hashing is no longer considered
cryptographic functionality, so using DES or MD5 to support legacy
password hashes is not a blocker to cryptographic certification of the
overall system.  There does not seem to be interest in certifying
libcrypt or libxcrypt anymore, as far as I can tell, and this is
probably the right call.

Thanks,
Florian