We don’t need to handle severe crosswinds. We just need to feel safe jumping out of airplanes.
Conversation
I’ve been downvoted on HN for making this point. I beg you, turn your back to that place if you ever want to do good engineering work.
7
13
253
There are, in fact, definitions of “good” that apply to non-cryptographic PRNGs. But non-invertability isn’t one of them. That’s a security property.
1
5
123
I want to live in a world where “random number generator” and “pseudorandom number generator” refer to secure things.
And there is this other class of things like “statistical sequence generator” that others can play with and make fast.
3
14
161
Ok I wrote down all my thoughts and will shut up now.
18
48
401
Replying to
I disagree that the number of people who need non-crypto RNGs is small, randomized algorithms are pretty common
2
2
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.
There should be a split between the general purpose API and a secure API with both provided by CSPRNGs with much different choices. Provide the overkill security margin and forward/backward secrecy for the secure API and keep the general purpose one fast so people stick to it.
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
Show replies