4 ms·

The API you describe, IIUC, can’t be serviced faithfully on the OSes targeted by std while being backed by real entropy.

by anp 7y ago

Macha 7y ago
Which is fine. Not everything needs SecureRandom. I'd wager more code using random numbers is for A/B tests, sample data generation or video games than people implementing crypto. I get that security people don't want non-secure RNGs to exist out of fear that someone might try implement security related functions out of them but why should I care if I just want to choose between 3 types of enemies this wave?
ChrisSD 7y ago
But the std hashmap implementation[0] already depends on a PRNG via the rand crate[1], and thus OS random (for the initial seed). So it's in the standard library even if you can't use it directly. Which is what makes me think this is an API issue, not an implementation one. [0]: https://doc.rust-lang.org/std/collections/hash_map/struct.RandomState.html https://doc.rust-lang.org/std/collections/hash_map/struct.Ra... [1]: https://docs.rs/rand/0.7.0/rand/rngs/struct.ThreadRng.html https://docs.rs/rand/0.7.0/rand/rngs/struct.ThreadRng.html
- anp 7y ago
  It does depend on this yes, but the random seed isn’t part of the public API. An RNG API in std would need to pick an algorithm and make that part of its stability guarantees.
  - ChrisSD 7y ago
    In this case I'd quibble that it wouldn't need to guarantee a specific algorithm, just a minimal set of properties. If the user can't manually set the seed then they'll be no expectation that it's deterministic or follows any particular algorithm. So the precise implementation can change with versions or even platforms. Javascript's Math.random and Crypto.getRandomValues works this way.
    - anp 7y ago
      Id say that in Rust’s case, we’ve already seen several painful examples of Hyrum’s law. http://www.hyrumslaw.com/ http://www.hyrumslaw.com/
Sean1708 7y ago
Why can't a simple API be backed by real entropy?

The API you describe, IIUC, can’t be serviced faithfully on the OSes targeted by std while being backed by real entropy.

by anp 7y ago

The API you describe, IIUC, can’t be serviced faithfully on the OSes targeted by std while being backed by real entropy.

Macha 7y ago

Which is fine. Not everything needs SecureRandom. I'd wager more code using random numbers is for A/B tests, sample data generation or video games than people implementing crypto. I get that security people don't want non-secure RNGs to exist out of fear that someone might try implement security related functions out of them but why should I care if I just want to choose between 3 types of enemies this wave?

ChrisSD 7y ago

But the std hashmap implementation[0] already depends on a PRNG via the rand crate[1], and thus OS random (for the initial seed). So it's in the standard library even if you can't use it directly. Which is what makes me think this is an API issue, not an implementation one. [0]: https://doc.rust-lang.org/std/collections/hash_map/struct.RandomState.html https://doc.rust-lang.org/std/collections/hash_map/struct.Ra... [1]: https://docs.rs/rand/0.7.0/rand/rngs/struct.ThreadRng.html https://docs.rs/rand/0.7.0/rand/rngs/struct.ThreadRng.html

anp 7y ago
It does depend on this yes, but the random seed isn’t part of the public API. An RNG API in std would need to pick an algorithm and make that part of its stability guarantees.
- ChrisSD 7y ago
  In this case I'd quibble that it wouldn't need to guarantee a specific algorithm, just a minimal set of properties. If the user can't manually set the seed then they'll be no expectation that it's deterministic or follows any particular algorithm. So the precise implementation can change with versions or even platforms. Javascript's Math.random and Crypto.getRandomValues works this way.
  - anp 7y ago
    Id say that in Rust’s case, we’ve already seen several painful examples of Hyrum’s law. http://www.hyrumslaw.com/ http://www.hyrumslaw.com/

Sean1708 7y ago

Why can't a simple API be backed by real entropy?