From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) by sourceware.org (Postfix) with ESMTPS id 8FBBC385694C for ; Thu, 16 Jun 2022 17:12:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8FBBC385694C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gont.com.ar Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=gont.com.ar Received: from [IPV6:2800:810:464:8944:f89f:c0a8:37d6:881a] (unknown [IPv6:2800:810:464:8944:f89f:c0a8:37d6:881a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 863BB2828DC; Thu, 16 Jun 2022 17:12:56 +0000 (UTC) Message-ID: <04aecb69-30db-f20b-e392-bff8b3fddc67@gont.com.ar> Date: Thu, 16 Jun 2022 14:12:51 -0300 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: en-US To: Adhemerval Zanella Cc: Libc-help References: From: Fernando Gont In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_NONE, TXREP, T_SCC_BODY_TEXT_LINE, T_SPF_PERMERROR 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:13:02 -0000 Hello, Adhemerval, Thanks a lot for your response! In-line.... 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? 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? Thanks! Regards, -- Fernando Gont e-mail: fernando@gont.com.ar PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1