> As for reliability, I don't know what "mediocre" means. Usually security- > critical code is correct or it's not. For a seed-source, either a lower > bound on > the amount of good "hard" randomness is available and reliable, or it's not.
We run in many environments, and I don't think it's reasonable to say that the RNG on someone's personal web server, perhaps on the Internet, is at the same level of criticality, say, as the same RNG running on something like a global CDN. I am not trying to back out of our responsibilities here, but rather saying that I think a justifiable case can be made for accepting vague words like mediocre at times. > That's moving the outer loop to the inside, for no good reason. That's a good way to put it, but there is a good reason for doing so. What should OpenSSL do when someone says "build for linux" Because pretty much right now that's all they can say. > -- If you trust this particular OS to provide a seed, why not > trust it for everything, and not bother to implement an > openssl-specfic RNG at all? Excellent question. The only answer I have so far is avoiding the syscall overhead when not needed. > If the questions are unanswerable for each individual OS, it seems both > impossible and pointless to try to answer them for all OSs at once. > The standard advice that you see on e.g. the crypto list is to use whatever > the OS provides. So is /dev/random to be used in the same way as getrandom(2)? That's not a rhetorical question. > In particular, if the ambient environment is not secure, it is very unlikely > that > anything openssl can do will make it secure. Suppose the chip supports RDRAND but the runtime doesn't have getrandom or /dev/random? > If what the OS provides isn't good enough, you should file bug reports > against it. It's not us, it's the people using it. We don't have the wherewithal or knowledge to do so. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
