4 ms·
> I genuinely don't see the reason why non-cryptographic random number generators exist outside of niche applications. Because for well over 99.99% of develope
by bigiain 6y ago
> I genuinely don't see the reason why non-cryptographic random number generators exist outside of niche applications.
Because for well over 99.99% of developers, cryptography is a “niche application”.
I’ve never written crypto code I’ve deployed anywhere. If I need crypto, I use the highest level crypto library I can find that people I trust who _do_ know about crypto recommend.
The only time I ever recall non cryptographic random() functions to have surprised or affected me was way back when I discovered if you forgot to seed the random on an AppleII the games I wrote in Basic all started out with the same “random” choices.
- hxtk 6y agoIt's true that most people who aren't doing sensitive work don't need cryptographically secure random number generators, but if you use something secure by default, it probably won't cause problems, and to the extent that it does you can catch them with some profiling. If you use insecure RNG by default, it probably won't cause problems but if it does you'll find them when a black hat hacker compromises your system in production. Very few people set out to roll their own crypto. The issue in my experience is less about someone writing their own hand-optimized password hash function and more about people having overly-narrow views of what counts as security critical code.
- tgsovlerkhgsel 6y agoCryptography is rare, but generating other data that needs to be unpredictable (e.g. session IDs, password reset tokens, random passwords getting generated, gift card codes, real-money gambling numbers) is quite common, I think. And the default implementation of random() doesn't seem to be any faster than AES-CTR (which is the core of one form of secure PRNG).