On Tue, May 12, 2020 at 10:00:20AM +0300, Andreas Gustafsson wrote: > This unfortunate situation should be addressed by providing more > entropy sources, not by burying our heads in the sand and pretending > we have entropy when we don't. Adding more sources could mean > reintroducing some timing based sources after careful analysis, but > also things like having the installer install an initial random seed > on the target machine (and if the installer itself lacks entropy, > asking the poor user to pound on the keyboard until it does). But > that's all outside the scope of this thread.
I disagree that measuring "full entropy" is something that's possible to do in a sane, fair, or uncontroversial way. The NetBSD kernel does not currently consider keyboard samples to provide strong randomness, their entropy is valued at 0 bits (although they are still added to the pool for next reseed). sysinst should provide an initial seed, that's very reasonable. On Tue, May 12, 2020 at 10:00:20AM +0300, Andreas Gustafsson wrote: > Specifically using kern.arandom for getentropy()? Which other > projects are these? On Tue, May 12, 2020 at 10:00:20AM +0300, Andreas Gustafsson wrote: > 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().
