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 CDCC43858296 for ; Thu, 16 Jun 2022 17:46:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CDCC43858296 Received: by mail-pj1-x1030.google.com with SMTP id t3-20020a17090a510300b001ea87ef9a3dso2115109pjh.4 for ; Thu, 16 Jun 2022 10:46:26 -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=ZFeRWEQKmvt2DIZsPcDJi256vWu3o2rg8cIIFG3w0ik=; b=XFNuA0aGMSTNijjQDcrA84dDwTRbiuUHHSuR97P2rwu2KpThOSPgzlmsZ9fVYjLx8C BThjT8DaKDM7DNvjuXahvAnsdILjgDe3o7yk7+WyoIPiTIXt7WIOL1EuDhEqOIfP83W4 0wb9NoDsYeBNZBsJRCc4+C9Pr+8olKpdmMAM5DQoDcGzrz9v04Oqf8tbZ4MFIl5z+jGx 3ArnZnGZ6cmM8Y5fkardewBWbdyVCveeo9RqFf3nKfl4VWS52sqObBkNYOP5NWJ0e9x4 j41XzVKZunjVzDZuNVT4iPocPEHpO6O4LUxQFUMf4sAEjWzMiVN6ooWdyRjntnFUBSej BxKg== X-Gm-Message-State: AJIora+vn3QGwIfGqHb+exFd4esMHtvwesOMaqb2X6R4CEgNOHGfzk/j jcaEX4grGJ0u7LqVzghzbpYsOOc/J4167nkx X-Google-Smtp-Source: AGRyM1s2KGTWKxDcpsgjDibwD214fPoO6e9VNdIpM/LPfsA/Ik6X14IfI4OoJZlyRyAUBP45KOQCEQ== X-Received: by 2002:a17:903:283:b0:163:be9d:483a with SMTP id j3-20020a170903028300b00163be9d483amr5596647plr.166.1655401585790; Thu, 16 Jun 2022 10:46:25 -0700 (PDT) Received: from smtpclient.apple ([192.77.111.2]) by smtp.gmail.com with ESMTPSA id g136-20020a62528e000000b0051bba89c2bcsm2071997pfb.58.2022.06.16.10.46.25 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Jun 2022 10:46:25 -0700 (PDT) Content-Type: text/plain; charset=utf-8 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: <0b0b2cfc-2a9c-86fa-3c61-920dd259cf28@opteya.com> Date: Thu, 16 Jun 2022 10:46:21 -0700 Cc: Fernando Gont , Libc-help Content-Transfer-Encoding: quoted-printable Message-Id: <5958FDBD-9BE5-46A4-86FB-BDCBD2238CB6@linaro.org> References: <04aecb69-30db-f20b-e392-bff8b3fddc67@gont.com.ar> <0b0b2cfc-2a9c-86fa-3c61-920dd259cf28@opteya.com> To: Yann Droneaud 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, 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: Thu, 16 Jun 2022 17:46:28 -0000 > On 16 Jun 2022, at 10:27, Yann Droneaud wrote: >=20 > Hi, >=20 > Le 16/06/2022 =C3=A0 19:12, Fernando Gont a =C3=A9crit : >>=20 >> On 15/6/22 15:00, Adhemerval Zanella wrote: >> [....] >>>> 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 >> One question here: >> If getentropy() ends up calling getrandom() to read from = /dev/urandom, my understanding is that it would never block. Is that = correct? >>=20 >=20 > getrandom() syscall will block until the kernel CSPRNG is fully = initialized (gathered enough entropy) after system boot. >=20 > After that, it will never block and behave like /dev/urandom. The = blocking behavior is mostly a problem for PID 1. Yes, and getrandom does not *read* /dev/urandom in the sense that it = uses a file descriptor to do so (I think it is worth to make it clear). And I think kernel is trying to improve this on recent releases, = although I do not know the current status. >=20 >=20 >> However, the manpage for getentropy(3) says: >> A call to getentropy() may block if the system has just booted >> and the kernel has not yet collected enough randomness to >> initialize the entropy pool. In this case, getentropy() will >> keep blocking even if a signal is handled, and will return = only >> once the entropy pool has been initialized. >>=20 >> Am I missing something? >>=20 >>=20 >> Aside, from what I read in the manual pages, getrandom()/getentropy() = e.g. does not result in a uniform distribution. So, in other words, one = can not really use them to comply with the requirements in RFC4086 = (i.e., as a cryptographically secure PRNG), but rather only use it as a = building block to build such a CSPRNG? >>=20 >=20 > Could you provide the part that state the output is not uniformly = distributed ? Indeed it is also new to me.