From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) by sourceware.org (Postfix) with ESMTPS id 65D803856DDD for ; Wed, 15 Jun 2022 20:29:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 65D803856DDD Received: by mail-pj1-x1030.google.com with SMTP id k5-20020a17090a404500b001e8875e6242so3064885pjg.5 for ; Wed, 15 Jun 2022 13:29:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=hZvIUd95t/BdPh2XLiiAkUUsfNZULl4h+jLfZD553Rk=; b=m0ZcwImXSD1BvPte7GVzehty4A37fnZ0YDQrEj1kJN7JHWj5Ksto0wlhFHgfCn0L2R vIhNNx9gV9eZMvHkEe9dsmZq8QHeMJttq6YIsVkMMlS/3QbkytUmCBK1k361Xkmds391 3QGOhYtEpfblNaofKI7nO9YsAW3ZFp4MWnmlgc9cRyYPn8icWj3abGZSvZNUTaOFHdu+ YD6dUOBYjII1NiBLeyDK2AcsYjwoK/hSsp7HrVKmdldoYRNjV5BSZI38QvIiv4WnjX1E hMSd6LJ66kdZ1emYd/5RQWDoZmiZWE5NNIazgpxuisXt0iaUBDQGtlLUvSyG7OlZ3WSY Hvgg== X-Gm-Message-State: AJIora/Z172+uJLbCj7amQAvm1Nmkq+TQk732eO3ae6ZAvCXl0+W3bVI 5kuDCphv8QQXexHu8eD0X6+U0g== X-Google-Smtp-Source: AGRyM1uyeiA8D1tMwro/AVvJfLhBcgQ3zwMDSHhmsQJob835ZMUusfbDK4I/Id7967YooqX/75FnFw== X-Received: by 2002:a17:902:bd8e:b0:167:6f86:7862 with SMTP id q14-20020a170902bd8e00b001676f867862mr1345927pls.15.1655324998097; Wed, 15 Jun 2022 13:29:58 -0700 (PDT) Received: from smtpclient.apple ([192.77.111.2]) by smtp.gmail.com with ESMTPSA id w1-20020a623001000000b0050dc762816fsm57624pfw.73.2022.06.15.13.29.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Jun 2022 13:29:57 -0700 (PDT) From: Adhemerval Zanella Message-Id: <1C6880D9-7578-4EF6-8689-5AAD23E2618E@linaro.org> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Subject: Re: getentropy() vs. getrandom() vs. arc4random() Date: Wed, 15 Jun 2022 13:29:56 -0700 In-Reply-To: Cc: Fernando Gont , Libc-help To: Noah Goldstein , Florian Weimer References: X-Mailer: Apple Mail (2.3696.100.31) X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, 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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 20:30:02 -0000 > On 15 Jun 2022, at 11:03, Noah Goldstein = wrote: >=20 > On Wed, Jun 15, 2022 at 11:01 AM Adhemerval Zanella via Libc-help > > wrote: >>=20 >>=20 >>=20 >>> 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? >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >> The arc4random also provides some more guarantees, like = fork-detection. >>=20 >> We are aiming to provide arc4random on new glibc version [1]. >>=20 >> [1] https://patchwork.sourceware.org/project/glibc/list/?series=3D9540 >=20 > Are there any blockers to this at the moment? >=20 > Wouldn't minding have some time before 2.36 to possibly look into the > x86_64 implementations. I think the last part is what missing some review (the TCB optimization = to make it lockless) and I am also waiting some feedback from Florian, since my = proposal is similar but uses a different strategy than his previous one.=