Many programs often need to generate high-quality random numbers for use in dealing with secret data. Programs made for CC:T, which currently doesn't provide entropy, end up either naively calling math.random (even after having it seeded with the system clock) or making use of some dubious unpredictability in low-resolution timers, events, or low-quality PRNGs.

I see 3 possible approaches to solving this:

• Providing a high-level random bytes and numbers API. This minimizes problems of incorrect usage universally.
• Providing a low-level random bytes API that samples from places like /dev/urandom. This would require user-made libraries for converting bytes to numbers and take into account the subtle biases in the conversion.
• Providing a high-resolution timer. Clock jitter RNGs are a thing, but have also been regarded as possibly riskier than raw OS randomness. This would be the least ad hoc solution and is even already implemented in CCEmuX. It would also require user-made libraries that deal with the even subtler biases.

Finally, one must also question whether the low-ish security environment of a Minecraft Computer even warrants such action. There's already precedent for changes like these in CC addons as well as OC modules. Personally, I think that even if the environment isn't that safe (from side channels to hackers and malicious server admins), solving this would shrink the attack surface for future software, as well as reduce uncertainty in the lives of some security library authors and users.

While /dev/urandom uses actual sources of entropy, are there any practical advantages of it over something like this api? (well, maybe not this specific one - have a feeling ISAAC is recommended against nowadays).

This is the problem:

Because computers are deterministic, if you can't get enough entropy then the output will be predictable, no matter how convoluted the process is. CSRNGs like ISAAC assume that they're seeded with high-quality entropy before any generation, but since there's no such thing in CC:T, the API just uses math.random and hopes that it's enough even though it's not.