| Message ID | 20220722122137.3270666-10-adhemerval.zanella@linaro.org |
|---|---|
| State | Accepted |
| Commit | ca4d3ea5130d66e66c5af14e958e99341bf20689 |
| Headers | show |
| Series | [v12,1/9] stdlib: Add arc4random, arc4random_buf, and arc4random_uniform (BZ #4417) | expand |
On 2022-07-22 8:21 AM, Adhemerval Zanella via Libc-alpha wrote: > +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? Isn't the whole point of arc4random that it _is_ cryptographically strong? zw
On 22/07/22 12:33, Zack Weinberg via Libc-alpha wrote: > On 2022-07-22 8:21 AM, Adhemerval Zanella via Libc-alpha wrote: >> +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? Isn't the whole point of arc4random that it _is_ cryptographically strong? > > zw Even OpenBSD manual is not clear about it [1]. This implementation is similar to OpenBSD, the main differences is that glibc implements a per-thread buffer instead of a global state (and although OpenBSD does think a global state is good qualitiy the are candid say they have no formal proof of these qualities [2]); and fork handling is done by glibc instead of relying on kernel (I do want to see if we can use a block allocator in this case). The main problem is if we state this is a CSRNG we need to certify somehow, which I don't have the background to do; and it might incur in extra certification depending of the intended glibc usage [2]. So I think it would be a more conservative approach to state our implementation is not a CSRNG (although it does follow most of the principles layout as fast-key-erasure random-number generators [4]). [1] https://sourceware.org/pipermail/libc-alpha/2022-July/140728.html [2] https://www.youtube.com/watch?v=gp_90-3R0pE [3] https://sourceware.org/pipermail/libc-alpha/2022-July/140782.html [4] http://blog.cr.yp.to/20170723-random.html
On Fri, Jul 22, 2022, at 1:15 PM, Adhemerval Zanella Netto wrote: > On 22/07/22 12:33, Zack Weinberg via Libc-alpha wrote: >> On 2022-07-22 8:21 AM, Adhemerval Zanella via Libc-alpha wrote: >>> +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? Isn't the whole point of arc4random that it _is_ >> cryptographically strong? > > Even OpenBSD manual is not clear about it [1]. ... > The main problem is if we state this is a CSRNG we need to certify > somehow, which I don't have the background to do; and it might incur > in extra certification depending of the intended glibc usage [2]. > So I think it would be a more conservative approach to state our > implementation is not a CSRNG ... My main concern with saying "still uses a Pseudo-Random Generator" and "should not be used in cryptographic contexts" is that, since we resisted adding this API for so long, people might think we did the bare minimum and it shouldn't actually be used at all. How about this? # These functions use a cryptographic-strength random number # generation _algorithm_ (currently ChaCha20) but the implementation # has not been validated for use in security-critical contexts. zw
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(+)