Re: PSA: Coders making ad hoc random schemes are like kids playing with matches.
OP,
I agree that cryptography is hell of a research domain specially for casual readers and hobbyists, and again I agree that programmers shouldn't try to forge homemade random generators, you nailed it, good job.
But I think you missed the main focus of the sources you referenced: The "/dev/random" vs "/dev/urandom" debate in the field of random number generation while presenting the whole subject as an untouchable topic, exclusively monopolized by a handful of people.
Like any research field, there are both simple and complex issues in cryptography, this debate happens to be a simple one, actually a non-existent one: There is a myth, largely believed, that implies urandom is not "secure enough" compared to "random" API, false claim based on a misinterpretation of the term "secure".
As long as the purpose of generating random numbers is to use them as seeds to electronic signature algorithms like RSA, ECDSA, Schnorr, etc., what matters is not pure mathematical/philosophical concept of security, because the ESA itself is not purely and information theoretically secure! Comparing the two APIs provided by unix like kernels, the myth gives more credit to /dev/random because of its inherent more guaranteed entropy.
But security is not a race between APIs, and it is where the myth falls apart, a good programmer or a qualified software engineer is not just like an ordinary customer shopping in a grocery store looking for "better" stuff, she desperately wants something fit for the application and preferably cheaper in terms of resource consumption.
As of our debate /dev/urandom is ways more adequate for generating pseudo random numbers as seeds for ESA simply because it is unpredictable more than enough for such schemes and the processing power needed for breaking it, could easily break the main algorithm in the first place if it'd ever exist, and more importantly, it is better choice compared to /dev/random because unlike the latter, it does not block!
That being said, it is worth mentioning there are always side channel risks, due to bad implementation/configuration practices for both APis under consideration.
So, you are absolutely right in discouraging programmers from cooking stupid random stuff and concluding that it is better to stick with /dev/urandom, but there is logic, simple logic, behind your recommendations that I'm afraid, you fail to present.
I agree that cryptography is hell of a research domain specially for casual readers and hobbyists, and again I agree that programmers shouldn't try to forge homemade random generators, you nailed it, good job.
But I think you missed the main focus of the sources you referenced: The "/dev/random" vs "/dev/urandom" debate in the field of random number generation while presenting the whole subject as an untouchable topic, exclusively monopolized by a handful of people.
Like any research field, there are both simple and complex issues in cryptography, this debate happens to be a simple one, actually a non-existent one: There is a myth, largely believed, that implies urandom is not "secure enough" compared to "random" API, false claim based on a misinterpretation of the term "secure".
As long as the purpose of generating random numbers is to use them as seeds to electronic signature algorithms like RSA, ECDSA, Schnorr, etc., what matters is not pure mathematical/philosophical concept of security, because the ESA itself is not purely and information theoretically secure! Comparing the two APIs provided by unix like kernels, the myth gives more credit to /dev/random because of its inherent more guaranteed entropy.
But security is not a race between APIs, and it is where the myth falls apart, a good programmer or a qualified software engineer is not just like an ordinary customer shopping in a grocery store looking for "better" stuff, she desperately wants something fit for the application and preferably cheaper in terms of resource consumption.
As of our debate /dev/urandom is ways more adequate for generating pseudo random numbers as seeds for ESA simply because it is unpredictable more than enough for such schemes and the processing power needed for breaking it, could easily break the main algorithm in the first place if it'd ever exist, and more importantly, it is better choice compared to /dev/random because unlike the latter, it does not block!
That being said, it is worth mentioning there are always side channel risks, due to bad implementation/configuration practices for both APis under consideration.
So, you are absolutely right in discouraging programmers from cooking stupid random stuff and concluding that it is better to stick with /dev/urandom, but there is logic, simple logic, behind your recommendations that I'm afraid, you fail to present.