I disagree that the number of people who need non-crypto RNGs is small, randomized algorithms are pretty common
Conversation
Replying to
My claim is that what’s small is the set of people who need randomized algorithms and ALSO have tight performance requirements that make CSPRNGs inappropriate.
These people know who they are and can shop for fast insecure generators, rather than having them be default.
3
14
For example we don’t optimize string operations in standard libraries to use fast streaming algorithms that would be appropriate for people doing large scale data processing (eg in HFT or “big science”) because we know those people have specific needs and can shop dependencies.
1
1
2
Replying to
people generally choose rust for very latency-sensitive applications, otherwise they would use a language with a garbage collector
1
Replying to
And these people can select a latency-appropriate *non-pseudo random* sequence generator that happens to have nice statistical properties.
1
1
Most would be more than happy with a fast CSPRNG but that isn't what they're being given as a default so they find that the CSPRNG is a performance bottleneck and turn to trying to find the fastest alternative. Give them speed by default and they wouldn't consider alternatives.
2
I’m thrilled for them to consider alternatives. If you’re in a space where the RNG is slowing things down, go ahead and install a replacement dependency.
Speeding your software up (by throwing out specific safety features) is something you do in the *optimization* phase.
1
When the default CSPRNG is commonly a performance issue, people are going to frequently turn elsewhere and are going to use those alternatives in libraries used by others too. Same issue with trying to force SipHash on everyone for hash tables and having them turn elsewhere.
1
1
Then they should turn elsewhere! By all means! Turn elsewhere!
This whole argument is like saying “my stdlib is too slow because it does bounds checking on string copies and some ultra-high performance libraries will be faster if we omit those”. Ok, fine! Go ahead.
1
I think the point of a stdlib is to handle common safety uses and for people who want performance and are positive they don’t need safety, they can use a carefully labeled “possibly_insecure” alternative. But of course if you name it that people get salty.
1
1
The failure is that it's entirely possible to give them both security and great performance.
CSPRNGs can provide great performance where almost no one would consider using anything else.
Hash DoS protection similarly doesn't require using SipHash in a way that destroys perf.