From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from brightrain.aerifal.cx (brightrain.aerifal.cx [216.12.86.13]) by sourceware.org (Postfix) with ESMTPS id D2DBA383A311 for ; Mon, 25 Jul 2022 17:41:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D2DBA383A311 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=libc.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=libc.org Date: Mon, 25 Jul 2022 13:41:38 -0400 From: Rich Felker To: Adhemerval Zanella Netto Cc: Florian Weimer , Yann Droneaud , "Jason A. Donenfeld" , libc-alpha@sourceware.org, Michael@phoronix.com, jann@thejh.net Subject: Re: arc4random - are you sure we want these? Message-ID: <20220725174138.GH7074@brightrain.aerifal.cx> References: <6bf352e9-1312-40de-4733-3219721b343c@linaro.org> <20220725153303.GF7074@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, SPF_HELO_NONE, SPF_NONE, TXREP 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-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2022 17:41:42 -0000 On Mon, Jul 25, 2022 at 12:59:39PM -0300, Adhemerval Zanella Netto via Libc-alpha wrote: > > > On 25/07/22 12:33, Rich Felker wrote: > > > > If this is just a case of trying to be "cautious" about overpromising > > things, the documentation needs fixed to specify that this is a > > CSPRNG. I'm particularly worried about the wording "these still use a > > Pseudo-Random generator and should not be used in cryptographic > > contexts". *All* CSPRNGs are PRNGs. Being pseudo-random does not make > > it not cryptographically safe. The safety depends on the original > > source of the entropy and the practical irreversibility and other > > cryptographic properties of the extension function. The fact that this > > has been stated so poorly in the documentation really has me worried > > that someone does not understand the issues. I haven't dug into the > > list mails or actual code to determine to what extent that's the case, > > but it's really, *really* worrying. > > That's the main drive to avoid calling CSPRNGs, since nor me or Florian > is secure enough to certify current scheme can actually follow all the > requirements. It does follow OpenBSD strategy of a fast-key-erasure > random-number generators, although all strategies of key reseeding are > basically heuristics. I think the core problem here is that, in making an implementation of a widely agreed-upon historical function with an existing working definition of what "cryptographically secure" means of a PRNG, you're instead positing a possibly-different definition of "CS" and saying "it might not be CS by this new definition". This does genuine harm to understanding of an area developers and users already understand very very poorly. The documentation should state that it's cryptographically secure in the sense normally meant for arc4random, which includes not falsely returning with "success" at early boot (no GRND_INSECURE or AT_RANDOM fallback), but that this does not necessarily include any guarantees about what happens in a program with undefined behavior ("hardening" properties) or things like actively trying to prevent you from cloning state (VM freeze/resume stuff, etc.) > If I understand Jason argument correctly, unless we have a kernel API > which it actually handles the buffer (so it can reseed or clear when it > seems fit), there is no point is proving a CSPRNGs in userspace, use > getrandom instead. As for me, I am in favor of having the interface, and would be fine with having it just wrap getentropy as an unlimited-length version thereof. The value is in having a commonly agreed upon API with common guarantees so as not to promote YOLO NIH of critical stuff like safe fallbacks for entropy. Rich