I’ve tested again how long I have to spend to test all combinations of the random module’s internal state with a piece of C code running on a Mac mini 2023 M2 Pro CPU. Result: slightly less than six (6) hours. See GitHub - jj1bdx/as183-c: AS183 PRNG C simulation code for further details. Note well that this result was obtained with a single core of M2 Pro, so if properly applying parallelism, the length of time will become much shorter to search all the internal state space with the brute-force method.
Remember the random module has been deprecated since OTP 19. If your code has a function call to random module, please use the rand module instead, right now.
The builtin random number generator algorithms are not cryptographically strong. If a cryptographically strong random number generator is needed, use something like crypto:rand_seed/0.
Sure, but then I don’t understand your strong warning against random. If neither of these are to be used for anything security-related, why would you care that its internal state can be exhaustively tested?
The limit of state space is a problem for any Monte Carlo algorithm e.g. because if it exhausts its state or is behaving less random one introduced a bias into such algorithms.
