I'm not a fan of this genre of HN posts, where we're encouraged to read lurid displays of (for lack of any better word, but without intending much value judgement) ignorance about some highly technical issue.<p>It's clear the Node team members do not have an especially good grasp on the problem here (you don't need to read all the way to the part where they talk about mixing in getpid to come to that conclusion).<p>It's also a little clear to me that the blunt-force approach of patrolling major open source projects for bad RNGs and demanding they replace them with urandom is <i>unlikely to be productive</i>. It becomes clear pretty quickly in this thread that the "no" votes have basically been cornered, message board flamewar style, and can't reconsider without losing face.<p>At the core of this discussion is a misunderstanding of the fundamental problem with elaborate CSPRNGs --- a misunderstanding the "urandom" votes here don't do a very good job of clearing up.<p>Specifically: the problem isn't <i>having enough entropy</i>; a very small amount of entropy can be cryptographically stretched into a practically unbounded feed of random bits. The value of adding more entropy is future secrecy (in effect: key rotation), which is a systems concern more than a cryptographic concern.<p>Rather, the problem with elaborate CSPRNGs is <i>the handling of whatever entropy you collect</i>, be it a mere 256 bits or a continuous running feed of userspace entropy. It's that concern that has repeatedly blown up crypto programs, and it's that concern that motivates us to rely on the kernel's systemwide random number generator rather than schemes like "egd", because the kernel CSPRNG is simpler, is a dependency in all systems anyways, can make promises about sharing that are hard for userspace programs to make, and can extract promises from the hardware that are not made directly to userspace programs.
tl;dr is basically on one side a suggestion to move away from the prng included in openssl because it could have bug, could be used wrong, and doesn't add anything from a cryptographic perspective and instead directly use the OS methods of generating randomness. There is then a lot of resistance to this on the grounds that fixing these theoretical bugs could add real bugs and considering how many OSs need to be supported this would trend towards rolling one's own crypto which the maintainers do NOT want to do.<p>There is openness though towards bundling libsodium and using it to generate randomness.
Blog post at <a href="https://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/" rel="nofollow">https://sockpuppet.org/blog/2014/02/25/safely-generate-rando...</a>
side question: any recommendations for a good, portable, linear prng in C++ we can embed in some proprietary code? We are doing some simulations which we run on multiple architectures and sometimes want to <i>re</i> run with different input parameters...and so want the same stream of "random" numbers for multiple runs.<p>My understanding (perhaps wrong?) is that open openSSL prng is exponential.