Re: arc4random - are you sure we want these?

[Rich Felker <dalias@libc.org>]

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