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. 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.
