[dead]
A Brief History of Random Numbers
31–40 of 55 posts
Re: A Brief History of Random Numbers
#32Earlier quoted context omitted.
Nowadays, you can just choose a CSPRNG and be done with it. There are not many use cases where you might prefer a simpler PRNG.
Are CSPRNGs as fast as general high-performance (and non-secure) PRNGs like MT, PGC or Xoroshiro256+? For many use cases in statistics / sampling / monte carlo simulations, you often need millions/billions of well-distributed random numbers with very low generation overhead. Even things like game AIs care about performance with regards to the RNGs they use.
Depends on what you compare, but with modern cryptography instructions you can now generate a few bytes per cycle, so billions of numbers is not an issue.
Re: A Brief History of Random Numbers
#33Earlier quoted context omitted.
Are CSPRNGs as fast as general high-performance (and non-secure) PRNGs like MT, PGC or Xoroshiro256+? For many use cases in statistics / sampling / monte carlo simulations, you often need millions/billions of well-distributed random numbers with very low generation overhead. Even things like game AIs care about performance with regards to the RNGs they use.
Not all of them, but ChaCha8 (which many renowned cryptographers consider secure[0]) is in the same ballpark as the most common ones[1]. (A few notes on the second link: I wouldn’t recommend xoshiro256+x8 since it is very weak statistically, same for xoshiro256 IMO. Also, disclaimer, I wrote SHISHUA.) [0]: https://eprint.iacr.org/2019/1492.pdf [1]: https://github.com/espadrine/shishua#comparison
In fairly comprehensive comparisons of PRNGs (MT, MTSMT, basic LGC, PGC and Xoroshiro256+) for genering random numbers for Monte Carlo sampling for pathtracing and simulation, generating both unit length float32s and shuffle indices, I found Xoroshiro256+ as good as the rest from a statistical sample distribution point-of-view (in terms of not being biased and providing excellent sample distribution in terms of converging to a ground-truth in many different simulations) and the fastest.
I don't dispute that at the bit level using something like PractRand it has issues and there are better "quality" ones, but at a practical sense in generating excellent 0.0f -> 1.0f float32 numbers and uint32_t indices I couldn't actually notice any quality issues with what it generated for very long running Monto Carlo simulations using billions of random numbers, even though it should have been causing issues with the integer numbers due to the weaker lower bits (although in practice, most of the indices were I wasn't aware of SHISHUA though, I'll check it out.
Re: A Brief History of Random Numbers
#34It amused me that my college statistics textbook had an appendix of random numbers in the back of the book. Just a long list of numbers generated at random and then immortalized on the same medium as ancient texts like the Dead Sea Scrolls. I guess that's the best we had for students before the widespread adoption of computers?
Back in the day, uniform random variates weren't that hard to come by, but if you wanted to simulate some normals, unless you wanted to do double table lookup plus maybe some interpolation, those tables were as convenient as it got.
You say that, but generating uniform variates was itself a whole trick. Famously RAND put a lot of effort into creating a ton of them and publishing them:
https://en.wikipedia.org/wiki/A_Million_Random_Digits_with_1...
Re: A Brief History of Random Numbers
#35Pseudo- random! A new programmer reading this article would come away with the impression that, if they need random numbers, they should use xorshift or PCG, when in reality they should be calling getentropy(), or, if a syscall is too expensive, using a CSPRNG (e.g. ChaCha or BLAKE3) seeded with getentropy(). We now have RNGs that are both secure and really, really fast -- multiple GB/s fast -- so there are very few…
Many people actually want low-discrepancy sequences anyway.
Re: A Brief History of Random Numbers
#36Why's he going on about slide-rules?
Stylistic flair.
Re: A Brief History of Random Numbers
#37Why's he going on about slide-rules?
good shorthand for "the time before computers, when math was done with meat and dinosaurs roamed the earth"
Re: A Brief History of Random Numbers
#38Learn more about PCG here: https://www.pcg-random.org/
Re: A Brief History of Random Numbers
#39Pseudo- random! A new programmer reading this article would come away with the impression that, if they need random numbers, they should use xorshift or PCG, when in reality they should be calling getentropy(), or, if a syscall is too expensive, using a CSPRNG (e.g. ChaCha or BLAKE3) seeded with getentropy(). We now have RNGs that are both secure and really, really fast -- multiple GB/s fast -- so there are very few…
> when in reality they should be calling getentropy() A new programmer shouldn't be meddling in cryptography, so they probably don't need either cryptographically-secure pseudo-random numbers nor true random numbers. True random numbers are tricky.
My whole point is that cryptographically-secure should be the default, as there are many scenarios where a PRNG leads to a security vulnerability where a CSPRNG would not. It is precisely new programmers who should be using CSPRNGs for everything, because they are the least well-equipped to know when strong entropy is necessary! We should (almost) never be asking "Do you really need a CSPRNG?" but rather "Do you really need a PRNG?"
Re: A Brief History of Random Numbers
#40Pseudo- random! A new programmer reading this article would come away with the impression that, if they need random numbers, they should use xorshift or PCG, when in reality they should be calling getentropy(), or, if a syscall is too expensive, using a CSPRNG (e.g. ChaCha or BLAKE3) seeded with getentropy(). We now have RNGs that are both secure and really, really fast -- multiple GB/s fast -- so there are very few…
If people call getentropy() when it;s not needed, it lowers entropy for places that do need it. There's not an infinite amount of crypto secure randomness available for all processes to go nuts sucking it up. This is one reason not to use getentropy as a PRNG - it will cause problems with other entropy needs. So advising people to just suck it up when they feel like it without truly needing it is a bad idea.
If one needs fast PRNGs, say for simulation, monte carlo stuff, etc. then CSPRNGs are a terrible idea. They're literally orders of magnitude slower than fast PRNGs. Almost nothing needs CSPRNGs (only things needing crypto level security, which is a tiny amount of the uses for PRNGs).
In short, use the right tool for the job.