On Wed, Jul 27, 2022 at 05:59:49PM -0400, Rich Felker wrote: > The only place I've heard of a viable "soft requirement" for real > entropy is for salting the hash function used in hash table maps to > harden them against DoS via intentional collisions. This is a small > but arguably legitimate usage domain. OK, so this is an issue that both Perl and Python have had to deal with, as described here: https://lwn.net/Articles/474912/ Is that fair description of the use case which you are describing? Because if it is, in the worst case, we only need a single random value for every http request made to the server. Would you agree with that? I think you'll find that even the original getrandom(2) system call or fetching a random value from /dev/urandom was plenty fast enough for this particular use case. If you're on some slow, ancient CPU, the webserver isn't going to be able to handle that many queries per second. And if you're on a fast CPU, the original /dev/urandom and/or getrandom(2) system call would be plenty fast enough. This is why both Jason and I have been trying to push people to clearly articular a specific use case and the attendant performance requirement, so we can test the hypothesis regarding how critical it is to have an userspace cryptographically secure RNG, with all of the attendant opportunities for security vulnerabilities in the face of VM snapshots, or VM's getting duplicated with a pre-spun execution image, etc., etc. Cheers, - Ted
