Hi Florian, On Mon, Jul 25, 2022 at 06:40:54PM +0200, Florian Weimer wrote: > The core issue is that on some kernels/architectures, reading from > /dev/urandom can degrade to GRND_INSECURE (approximately), and while the > result is likely still unpredictable, not everyone would label that as a > CSPRNG. On some old kernels (though I think not all?), you can poll on /dev/random. This isn't perfect, as the ancient "non blocking pool" initialized after the "blocking pool", but it's not too imperfect either. Take a look at the previously linked random-util.c. > If we document arc4random as a CSPRNG, this means that we would have to > ditch the fallback code and abort the process if the getrandom system > call is not available: when reading from /dev/urandom as a fallback, we > have no way of knowing if we are in any of the impacted execution > environments. Based on your other comments, it seems that you are > interested in such fallbacks, too, but I don't think you can actually > have both (CSPRNG + fallback). > > And then there is the certification issue. We really want applications > that already use OpenSSL for other cryptography to use RAND_bytes > instead of arc4random. Likewise for GNUTLS and gnutls_rnd. What should > authors of those cryptographic libraries? That's less clear, and really > depends on the constraints they operate in (e.g., they may target only a > subset of architectures and kernel versions). I think all of this is yet another indication that there are some major things to work out -- should we block or not? is buffering safe? is the interface correct? -- and so we should just back out the arc4random commit until this has been explored a bit more. We're not gaining anything from rushing this, especially as a "source code compatibility" thing, if there's not even agreement between OSes on what the function does inside. Jason PS: please try to keep linux-crypto@xxxxxxxxxxxxxxx CC'd. I've been bouncing these manually when not, but it's hard to keep up with that.
