Hi Ted, On Sun, Sep 15, 2019 at 10:49:04PM -0400, Theodore Y. Ts'o wrote: > No matter *what* we do, it's going to either (a) make some > systems insecure, or (b) make some systems more likely hang while > booting. I continue to strongly disagree with opposing these two. (b) is caused precisely because of this conflation. Life long keys are produced around once per system's life (at least this order of magnitude). Boot happens way more often. Users would not complain that systems fail to start if the two types of random are properly distinguished so that we don't fail to boot just for the sake of secure randoms that will never be consumed as such. Before systems had HWRNGs it was pretty common for some tools to ask the user to type hundreds of characters on the keyboard and use that (content+timings) to feed entropy while generating a key. This is acceptable once in a system's life. And on some systems with no entropy like VMs, it's commonly generated from a central place and never from the VM itself, so it's not a problem either. In my opinion the problem recently happened because getrandom() was perceived as a good replacement for /dev/urandom and is way more convenient to use, so applications progressively started to use it without realizing that contrary to its ancestor it can block. And each time a system fails to boot confirms that entropy still remains a problem even on PCs in 2019. This is one more reason for clearly keeping two interfaces depending on what type of random is needed. I'd be in favor of adding in the man page something like "this random source is only suitable for applications which will not be harmed by getting a predictable value on output, and as such it is not suitable for generation of system keys or passwords, please use GRND_RANDOM for this". This distinction currently is not clear enough for people who don't know this subtle difference, and can increase the interface's misuse. Regards, Willy
