From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by sourceware.org (Postfix) with ESMTPS id 818CB3857360 for ; Thu, 16 Jun 2022 17:27:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 818CB3857360 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=opteya.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=opteya.com Received: from [IPV6:2a01:e35:39f2:1220:a34e:e96f:a490:4e2a] (unknown [IPv6:2a01:e35:39f2:1220:a34e:e96f:a490:4e2a]) by smtp1-g21.free.fr (Postfix) with ESMTPS id 96195B00563; Thu, 16 Jun 2022 19:27:12 +0200 (CEST) Message-ID: <0b0b2cfc-2a9c-86fa-3c61-920dd259cf28@opteya.com> Date: Thu, 16 Jun 2022 19:27:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: getentropy() vs. getrandom() vs. arc4random() Content-Language: fr-FR To: Fernando Gont , Adhemerval Zanella Cc: Libc-help References: <04aecb69-30db-f20b-e392-bff8b3fddc67@gont.com.ar> From: Yann Droneaud Organization: OPTEYA In-Reply-To: <04aecb69-30db-f20b-e392-bff8b3fddc67@gont.com.ar> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00, BODY_8BITS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_SOFTFAIL, 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: Thu, 16 Jun 2022 17:27:18 -0000 Hi, Le 16/06/2022 à 19:12, Fernando Gont a écrit : > > On 15/6/22 15:00, Adhemerval Zanella wrote: > [....] >>> 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). >> >> 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. > > 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? > getrandom() syscall will block until the kernel CSPRNG is fully initialized (gathered enough entropy) after system boot. After that, it will never block and behave like /dev/urandom. The blocking behavior is mostly a problem for PID 1. > 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. > > Am I missing something? > > > 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? > Could you provide the part that state the output is not uniformly distributed ? Regards. -- Yann Droneaud OPTEYA