Joerg Sonnenberger wrote: > > For the OpenBSD strategy to work, the system needs to actually refuse > > to run if the seed can't be loaded (or full entropy achieved in some > > other way). NetBSD doesn't do that. As long as there is any way > > userland can start before full entropy has been achieved, all APIs > > that provide randomness for security purposes must support blocking > > (or returning errors). > > Why? Like I said, we don't have a working 127.0.0.1 when userland starts > and that is an essential part of the Unix network stack.
Because if the APIs return data before full entropy has been achieved, rather than blocking (or failing), the data returned may be predictable, leading to silent security failures such as the generation of guessable encryption keys. I'm not familiar with the 127.0.0.1 issue, but presumably it does not have such security implications. Are you suggesting that instead of blocking calls, we should use something akin to the ordering of rc scripts that ensures 127.0.0.1 is set up before use to ensure entropy is available before it is needed? That could work, assuming entropy is available at all, but in that case any premature calls to the randomness APIs ought to return errors so that bugs in the ordering can be detected rather than causing silent generation of predictable randomness. -- Andreas Gustafsson, g...@gson.org
