On Sat, Sep 14, 2019 at 10:05:21PM -0400, Theodore Y. Ts'o wrote: > You basically want to turn getrandom into /dev/urandom. And that's > how we got into the mess where 10% of the publically accessible ssh > keys could be guessed. Not exactly. This was an *API* issue that created this situation. The fact that you had a single random() call in the libc, either mapped to /dev/urandom or to /dev/random. By then many of us were used to rely on one or the other and finding systems where /dev/random was a symlink to /dev/urandom to avoid blocking was extremely common. In fact it was caused by the exact same situation: we try to enforce good random for everyone, it cannot work all the time and breaks programs which do not need such randoms, so the user breaks the trust on randomness by configuring the system so that randoms work all the time for the most common programs. And that's how you end up with SSH trusting a broken random generator without knowing it was misconfigured. Your getrandom() API does have the ability to fix this. In my opinion the best way to proceed is to consider that all those who don't care about randomness quality never block and that those who care can be sure they will either get good randoms or will know about it. Ideally calling getrandom() without any flag should be equivalent to what you have with /dev/urandom and be good enough to put a UUID on a file system. And calling it with "SECURE" or something like this will be the indication that it will not betray you and will only return good randoms (which is what GRND_RANDOM does in my opinion). The huge difference between getrandom() and /dev/*random here is that each application can decide what type of random to use without relying on what system-wide breakage was applied just for the sake of fixing another simple application. This could even help OpenSSL use two different calls for RAND_bytes() and RAND_pseudo_bytes(), instead of using the same call and blocking. Last but not least, I think we need to educate developers regarding random number consumption, asking "if you could produce only 16 bytes of random in your whole system's lifetime, where would you use them?". Entropy is extremely precious and yet the most poorly used resource. I almost wouldn't mind seeing GRND_RANDOM requiring a special capability since it does have a system-wide impact! Regards, Willy
