> In short, as long as a modest bit of work is put into optimization, this will > never come close to being anybody's bottleneck. And it's worth doing to avoid > the MANY issues I've seen over the years where people didn't give it a second > thought, and ended up totally owned.
This should be discussed in a RFC but is factually wrong. AES is way slower than xoroshiro128++. RNG speed is a bottleneck in machine learning that needs to generate millions of samples to populate model weights. It's also a bottleneck in Monte Carlo simulation as used in Finance or game AI via Monte-Carlo Tree Search. Lastly there is a marketing aspect as well, in benchmarks people often use the default RNG for mini-benches and having it unnecessarily slow will just reflect poorly on those. Regarding RNG, another recurring issue is that people use them wrongly in a multithreaded context, but they are not threadsafe. For cryptography purposes, as you said earlier libraries should be monolith with everything taken care of. And it should be (and is) highlighted that the RNG is not suitable for cryptographic purposes: <https://nim-lang.org/docs/random.html> re @pietroppeter > how to use crypto is definitely more difficult and require special expertise > than how to implement crypto. Actually, implementing crypto correctly and misuse resistant is far harder than using crypto. The issue with using crypto is than many libraries expose everything and you have unsafe non-sensical combination exposed. The poster child of this is "If openssl was a GUI": <https://smallstep.com/blog/if-openssl-were-a-gui/>
