From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-x1132.google.com (mail-yw1-x1132.google.com [IPv6:2607:f8b0:4864:20::1132]) by sourceware.org (Postfix) with ESMTPS id 7A4153858D32 for ; Wed, 15 Jun 2022 18:03:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7A4153858D32 Received: by mail-yw1-x1132.google.com with SMTP id 00721157ae682-30c2f288f13so69221877b3.7 for ; Wed, 15 Jun 2022 11:03:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=PdYMQQwXrAgSOkzpwixwNJVNyhr1A0Q63Dc+uJeDXso=; b=S+SCKtg+eFdIv2KVtxvYLS+c1ND7N6Rb/iS6G3YSVpbdXXB+WNpjTj+sVOamvC5mBE pjU2MPSD6Qke/HjY6EvurCybEgx0MUigyLD/1l/50gqRTpJ2IpMMuALbV5ZM9rxvP+Tz 7T6Kh3ZmplKT/+f/17oq1wzTbQJ3nmJCPs+8vZOSevvZ4IDSJWzf8G75q5qc7K8BZ/2M VS2tnwSyLwHkEA3hsjpXFKzc34jp5Q7qqQ46k+LFK6NQWfrBLutihX8DDzbtSUluzRdf RgxulSomZUCq768IMGtz0SZ6s0gDU2Meqm8g2uG+zInbRUTlH6mqZkqyTR4RdySpAUyS blZQ== X-Gm-Message-State: AJIora87ByZbYR5f1xGgBY7adnMFVMROJ4eHuoRY3tBslUULGdxDWuhl T2PYs2PM1iS9FBzfXaWICVUv4CRByQotmtALbrF+cR479Ac= X-Google-Smtp-Source: AGRyM1tEObBQSk46jXJB+O0Ar2nEWpmYV1k56ubxqVFYvcpvTRCl177mfFKCI2IcxTostfe9qZHxBWDJBsRBR6ku2+Y= X-Received: by 2002:a81:7bd5:0:b0:313:e8d8:d5eb with SMTP id w204-20020a817bd5000000b00313e8d8d5ebmr926802ywc.473.1655316220879; Wed, 15 Jun 2022 11:03:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Noah Goldstein Date: Wed, 15 Jun 2022 11:03:30 -0700 Message-ID: Subject: Re: getentropy() vs. getrandom() vs. arc4random() To: Adhemerval Zanella Cc: Fernando Gont , Libc-help Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2022 18:03:44 -0000 On Wed, Jun 15, 2022 at 11:01 AM Adhemerval Zanella via Libc-help wrote: > > > > > On 15 Jun 2022, at 07:24, Fernando Gont wrote: > > > > Hi, > > > > I'm currently trying to grasp the functional differences in the differe= nt interfaces to generate pseudorandom numbers in different platforms. And = I was wondering if you could shed some light on some questions I have. > > > > > > ** Brief Background: ** > > > > We're working on a document where we warn users about the security impl= ications of using rand() and random() to generate pseudorandom numbers (in = scenarios where cryptographically secure pseudorandom numbers are needed). > > > > So we want to recommend better PRNG options for different operating sys= tems. For example, in the case of OpenBSD, we recommend the use of arc4rand= om(3), which provides a higher-level interface than the getentropy(2) syste= m call. > > > > However, we're unsure about what to recommend for the Linux case. > > > > For the Linux case, I see that there's a lot of code using getrandom(2)= -- a syscall --, which is kind of complex/too-low-level. And I see that Li= nux also has getentropy(3) library function, which is described in random(7= ) as a "more portable interface the underlying PRNG devices". > > > > So, for the Linux case, I feel tempted to recommend the usage of getent= ropy(3) over getrandom(2), but since most code employs getrandom(2), I'm no= t sure whether I'm missing something. > > > > Any thoughts? > > > > Aside, it seems that for OpenBSD, getentropy(2) is a "low-level" syscal= l, while arc4random(3) is a high-level library function. But in the case of= Linux, getentropy(3) is a high-level library function instead, while getra= ndom(2) is the low-level syscall. -- which means that usage of these inte= rfaces would probably not be consistent across platforms. > > > > Is this actually the case? > > On glibc, getentropy and getrandom both end calling getrandom syscall alt= hough > with different flags. The getentropy calls getrandom without any flag whi= ch in turn > get entropy from /dev/urandom. The getrandom function allows us to specif= y > which source you use through GRND_RANDOM flag. > > Also, getentropy current has a hard limit of maximum of 256 bytes and it = is not > defined a cancelation entrypoint (so pthread_cancel does not act upon it)= . > > So both functions drawn entropy direct from the kernel and with recent Li= nux > random number development to unify both random and urandom the difference > might ended up with just getentropy being a cancellation entrypoint. > > The rand and random functions are both userspace only where caller should= set > PRNG state and both returns predictable output based on the initial seed.= On glibc > both are implemented with either a LGC or a polynomial generated, set by = the > seed size. So the quality of the output will depend of the seed entropy a= nd the > limitation of the polynomial used. > > The arc4random is similar to getentropy and getrandom, but it tries to us= e kernel > entropy to initialize a PRNG. Also, the usual implementation that uses Ch= aCha20 > (OpenBSD, FreeBSD) periodically feeds back kernel entropy to improve rand= omness. > The arc4random also provides some more guarantees, like fork-detection. > > We are aiming to provide arc4random on new glibc version [1]. > > [1] https://patchwork.sourceware.org/project/glibc/list/?series=3D9540 Are there any blockers to this at the moment? Wouldn't minding have some time before 2.36 to possibly look into the x86_64 implementations. > > > > > > > FWIW, if you're curious, the document we're working on is this one: htt= ps://www.ietf.org/archive/id/draft-irtf-pearg-numeric-ids-generation-10.txt= , and the section that led me to start this thread is Section 7.1: > > > > ----- cut here ---- > > 7.1. Category #1: Uniqueness (soft failure) > > > > The requirement of uniqueness with a soft failure severity can be > > complied with a Pseudo-Random Number Generator (PRNG). > > > > NOTE: > > Please see [RFC4086] regarding randomness requirements for > > security. > > > > While most systems provide access to a PRNG, many of such PRNG > > implementations are not cryptographically secure, and therefore might > > be statistically biased or subject to adversarial influence. For > > example, ISO C [C11] rand(3) implementations are not > > cryptographically secure. > > > > NOTE: > > Section 7.1 ("Uniform Deviates") of [Press1992] discusses the > > underlying issues affecting ISO C [C11] rand(3) implementations. > > > > On the other hand, a number of systems provide an interface to a > > Cryptographically Secure PRNG (CSPRNG) [RFC8937] [RFC4086], which > > guarantees high entropy, unpredictability, and good statistical > > distribution of the random values generated. For example, GNU/ > > Linux's CSPRNG implementation is available via the getentropy(3) > > interface [GETENTROPY], while OpenBSD's CSPRNG implementation is > > available via the arc4random(3) and arc4random_uniform(3) interfaces > > [ARC4RANDOM]. Where available, these CSPRNGs should be preferred > > over e.g. POSIX [POSIX] random(3) or ISO C [C11] rand(3) > > implementations. > > > > In scenarios where a CSPRNG is not readily available to select > > transient numeric identifiers of Category #1, a security and privacy > > assessment of employing a regular PRNG should be performed, > > supporting the implementation decision. > > > > NOTE: > > [Aumasson2018], [Press1992], and [Knuth1983], discuss theoretical > > and practical aspects of pseudorandom numbers generation, and > > provide guidance on how to evaluate PRNGs. > > > > We note that since the premise is that collisions of transient > > numeric identifiers of this category only leads to soft failures, in > > many cases, the algorithm might not need to check the suitability of > > a selected identifier (i.e., the suitable_id() function, described > > below, could always return "true"). > > ---- cut here ---- > > > > Thanks a lot in advance! > > > > Regards, > > -- > > Fernando Gont > > e-mail: fernando@gont.com.ar > > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >