| Message ID | 20220714112845.704678-10-adhemerval.zanella@linaro.org |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v10,1/9] stdlib: Add arc4random, arc4random_buf, and arc4random_uniform (BZ #4417) | expand |
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
diff --git a/manual/math.texi b/manual/math.texi index 477a18b6d1..141695cc30 100644 --- a/manual/math.texi +++ b/manual/math.texi @@ -1447,6 +1447,7 @@ systems. * ISO Random:: @code{rand} and friends. * BSD Random:: @code{random} and friends. * SVID Random:: @code{drand48} and friends. +* High Quality Random:: @code{arc4random} and friends. @end menu @node ISO Random @@ -1985,6 +1986,51 @@ This function is a GNU extension and should not be used in portable programs. @end deftypefun +@node High Quality Random +@subsection High Quality Random Number Functions + +This section describes the random number functions provided as a GNU +extension, based on OpenBSD interfaces. + +@Theglibc{} uses kernel entropy obtained either through @code{getrandom} +or by reading @file{/dev/urandom} to seed and periodically re-seed the +internal state. A per-thread data pool is used, which allows fast output +generation. + +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. + +The internal state is cleared and reseeded with kernel entropy on @code{fork} +and @code{_Fork}. It is not cleared on either a direct @code{clone} syscall +or when using @theglibc{} @code{syscall} function. + +The prototypes for these functions are in @file{stdlib.h}. +@pindex stdlib.h + +@deftypefun uint32_t arc4random (void) +@standards{BSD, stdlib.h} +@safety{@mtsafe{}@asunsafe{@asucorrupt{}}@acsafe{}} +This function returns a single 32-bit value in the range of @code{0} to +@code{2^32−1} (inclusive), which is twice the range of @code{rand} and +@code{random}. +@end deftypefun + +@deftypefun void arc4random_buf (void *@var{buffer}, size_t @var{length}) +@standards{BSD, stdlib.h} +@safety{@mtsafe{}@asunsafe{@asucorrupt{}}@acsafe{}} +This function fills the region @var{buffer} of length @var{length} bytes +with random data. +@end deftypefun + +@deftypefun uint32_t arc4random_uniform (uint32_t @var{upper_bound}) +@standards{BSD, stdlib.h} +@safety{@mtsafe{}@asunsafe{@asucorrupt{}}@acsafe{}} +This function returns a single 32-bit value, uniformly distributed but +less than the @var{upper_bound}. It avoids the @w{modulo bias} when the +upper bound is not a power of two. +@end deftypefun + @node FP Function Optimizations @section Is Fast Code or Small Code preferred? @cindex Optimization
From: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> --- manual/math.texi | 46 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+)