nia wrote: > I disagree that measuring "full entropy" is something that's possible > to do in a sane, fair, or uncontroversial way.
Advocating the use of /dev/urandom and its equivalents on that basis basically boils down to "because we can't agree on what level of security we should require or how to measure it, we shall require no security at all". And that I very much disagree with. I don't particularly care if we require 100 or 384 bits of estimated entropy, nor do I particularly care if the entropy estimate of a keystroke timestamp is 0 or 1 bit. But I do very much care that if I accidentally try to generate an ssh key on a system that has no entropy at all, it must not succeed. > > kern.arandom may be nonblocking and sandbox-safe, but it is not suitable > > for security critical applications. > > These use arandom exclusively on NetBSD: > - gnutls (via nettle _rnd_get_system_entropy) > Prefers getentropy and only uses getrandom if there's no getentropy. > - openssl (syscall_random) > Prefers getentropy and only uses getrandom if there's no getentropy. > - libuv (uv__random) > Prefers getentropy on macOS and Android. > - rust (getrandom crate, standard library and compiler) > - FreeBSD libc (to implement getentropy) > > These use urandom exclusively on NetBSD: > - NSS > Prefers getentropy(). Contains no support for getrandom() or arandom. > - mbedtls > Only supports using the getrandom() syscall directly on Linux. > Assumes nothing is provided by libc. > - Python > Prefers getrandom(), due to bugs in Solaris' getentropy(). Thank you for the lists. I need some more time to look at each item in detail, but at first glance, most of them look like ones I think ought to use /dev/random or equivalent. -- Andreas Gustafsson, g...@gson.org
