Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Supplying high-quality entropy to programs #818

Open
migeyel opened this issue Jun 9, 2021 · 2 comments
Open

Supplying high-quality entropy to programs #818

migeyel opened this issue Jun 9, 2021 · 2 comments
Labels
area-Core This affects CC's core (the Lua runtime, APIs, computer internals). enhancement An extension of a feature or a new feature.

Comments

@migeyel
Copy link

migeyel commented Jun 9, 2021

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.

@migeyel migeyel added the enhancement An extension of a feature or a new feature. label Jun 9, 2021
@SquidDev
Copy link
Member

SquidDev commented Jun 9, 2021

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).

@migeyel
Copy link
Author

migeyel commented Jun 9, 2021

This is the problem:
Screenshot from 2021-06-09 19-15-26
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.

@SquidDev SquidDev added area-CraftOS This affects CraftOS, or any other Lua portions of the mod. area-Core This affects CC's core (the Lua runtime, APIs, computer internals). and removed area-CraftOS This affects CraftOS, or any other Lua portions of the mod. labels Jun 12, 2021
@migeyel migeyel mentioned this issue Jul 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-Core This affects CC's core (the Lua runtime, APIs, computer internals). enhancement An extension of a feature or a new feature.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants