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.
For crypto one shouldn’t use
rand either, right?
No, you MUST NOT use rand module at all either, for any cryptographic use.
The documentation writes:
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.