From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) by sourceware.org (Postfix) with ESMTPS id 06ABE3858D32 for ; Wed, 15 Jun 2022 18:01:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 06ABE3858D32 Received: by mail-pf1-x42c.google.com with SMTP id w21so12171094pfc.0 for ; Wed, 15 Jun 2022 11:01:00 -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:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ffmm9b2rsYVaQIxJmNYd3DLrDf11/GEhyBjlR2uZkFM=; b=IqNRr+FM00NUdhDZ7LgmySGMBZr+vkKThSBrRJckuHF8NuecKvKEMnqVl8REUGQr6P kz+bdrGa4DrquAIorjniu7xqh+q2H4njsxH9js6jiWENOx4UmQFGPaXGeIxl2sdLpG8e yYUBJqJX9cIh40aLRk054weXxv72vnlGoH2/mq6HD4UN9Ya0mNqXEplX53Z9urj1gFH9 I/pia559QAN5aKoBPbguBQMVwW75UweuR/TJCchABTVEc3tgjENfTyxcsx9zP0dOD7jL VJH26GV2AbXkR+S0atP36GIWqTkWlXmkMMOoYrQxVV/bGwRMgebmjh/FALWyDb4SUKIA fSfQ== X-Gm-Message-State: AJIora9EpWyAvzSD7akq+j9iT/4xNJkQ8EgZZZ5f3fRSk3i5ZtMMSx4Y mYzErgR3CUYbCNYrE2Fg0tV5aVc3PuIiFRS7 X-Google-Smtp-Source: AGRyM1tyYXF8MGIJ0PrY4SyLq+uj8YLmORvbBAwpgm1dwJoDDvp3dIDX8Y2dxy1CocH29ONao0EShQ== X-Received: by 2002:a63:1447:0:b0:408:82f7:24f9 with SMTP id 7-20020a631447000000b0040882f724f9mr852571pgu.303.1655316059819; Wed, 15 Jun 2022 11:00:59 -0700 (PDT) Received: from smtpclient.apple ([192.77.111.2]) by smtp.gmail.com with ESMTPSA id n12-20020a056a00212c00b00518950bfc82sm499164pfj.10.2022.06.15.11.00.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Jun 2022 11:00:59 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Subject: Re: getentropy() vs. getrandom() vs. arc4random() From: Adhemerval Zanella In-Reply-To: Date: Wed, 15 Jun 2022 11:00:58 -0700 Cc: Libc-help Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Fernando Gont X-Mailer: Apple Mail (2.3696.100.31) X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no 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:01:03 -0000 > On 15 Jun 2022, at 07:24, Fernando Gont wrote: >=20 > Hi, >=20 > I'm currently trying to grasp the functional differences in the = different interfaces to generate pseudorandom numbers in different = platforms. And I was wondering if you could shed some light on some = questions I have. >=20 >=20 > ** Brief Background: ** >=20 > We're working on a document where we warn users about the security = implications of using rand() and random() to generate pseudorandom = numbers (in scenarios where cryptographically secure pseudorandom = numbers are needed). >=20 > So we want to recommend better PRNG options for different operating = systems. For example, in the case of OpenBSD, we recommend the use of = arc4random(3), which provides a higher-level interface than the = getentropy(2) system call. >=20 > However, we're unsure about what to recommend for the Linux case. >=20 > 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 Linux also has getentropy(3) library function, which is = described in random(7) as a "more portable interface the underlying PRNG = devices". >=20 > So, for the Linux case, I feel tempted to recommend the usage of = getentropy(3) over getrandom(2), but since most code employs = getrandom(2), I'm not sure whether I'm missing something. >=20 > Any thoughts? >=20 > Aside, it seems that for OpenBSD, getentropy(2) is a "low-level" = syscall, 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 getrandom(2) is the low-level syscall. -- which means = that usage of these interfaces would probably not be consistent across = platforms. >=20 > Is this actually the case? On glibc, getentropy and getrandom both end calling getrandom syscall = although with different flags. The getentropy calls getrandom without any flag = which in turn get entropy from /dev/urandom. The getrandom function allows us to = specify 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).=20 So both functions drawn entropy direct from the kernel and with recent = Linux 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 = and the limitation of the polynomial used. The arc4random is similar to getentropy and getrandom, but it tries to = use kernel entropy to initialize a PRNG. Also, the usual implementation that uses = ChaCha20 (OpenBSD, FreeBSD) periodically feeds back kernel entropy to improve = randomness.=20 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 >=20 >=20 > FWIW, if you're curious, the document we're working on is this one: = https://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: >=20 > ----- cut here ---- > 7.1. Category #1: Uniqueness (soft failure) >=20 > The requirement of uniqueness with a soft failure severity can be > complied with a Pseudo-Random Number Generator (PRNG). >=20 > NOTE: > Please see [RFC4086] regarding randomness requirements for > security. >=20 > 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. >=20 > NOTE: > Section 7.1 ("Uniform Deviates") of [Press1992] discusses the > underlying issues affecting ISO C [C11] rand(3) implementations. >=20 > 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. >=20 > 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. >=20 > NOTE: > [Aumasson2018], [Press1992], and [Knuth1983], discuss theoretical > and practical aspects of pseudorandom numbers generation, and > provide guidance on how to evaluate PRNGs. >=20 > 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 ---- >=20 > Thanks a lot in advance! >=20 > Regards, > --=20 > Fernando Gont > e-mail: fernando@gont.com.ar > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1