4 ms·
Just use PCG or XorShift* (in non-cryptographic contexts), they avoid almost all of the pitfalls while still having almost all of the low-overhead benefits htt
by vanderZwan 6y ago
Just use PCG or XorShift* (in non-cryptographic contexts), they avoid almost all of the pitfalls while still having almost all of the low-overhead benefits
https://www.pcg-random.org/ https://www.pcg-random.org/
- hinkley 6y agoI think it’s important to address the fact that there is a different answer for different contexts. There is no, “just”. It’s always a decision tree. The comparison table there has some good food for thought, but it doesn’t cover the entire space. There are other CSPRNG classes not listed here, which have been used in various programming languages to generate TLS session keys, for instance. If I’m creating a computer game for a console, then I probably don’t care too much about most of these (until someone has figured out how to cheat).
- vanderZwan 6y agoSure, but I was specifically replying to the context where one might consider using LCGs. I can think of few cases where the performance requirements are so tight that one would consider those but PCG or XorShift* is out of the question as an alternative. > If I’m creating a computer game for a console, then I probably don’t care too much about most of these (until someone has figured out how to cheat). If there is any place where people care a lot about eking out the last bit of performance (not to mention predictability of pseudorandomness with specific seeds) it's game design
- im3w1l 6y agoNot using a CSPRNG for everything and anything sounds like premature optimization to me. I mean sure, if you need randomness in a very tight loop, make a tradeoff.