4 ms·

I tend to agree. The determinism of random() is a feature, but it's a feature that almost nobody actually needs. It's just that the alternatives are either mo

by bmm6o 12y ago

I tend to agree. The determinism of random() is a feature, but it's a feature that almost nobody actually needs. It's just that the alternatives are either more trouble than they're worth or platform-dependent.

kevin_thibedeau 12y ago
I use the determinism with test cases generating random input data. Every run of a test case generates a random seed based off the system time and reports the seed used. When a failure happens, the seed is fixed using an environment variable. Then the failed case can be reproduced until the bug is tracked down. This isn't an unusual practice. The determinism in standard PRNG functions is an important feature not a weakness. Theo is being foolish. If he's unhappy with the way the *rand functions are being used he should just change the code calling into the library to use random seeds derived from a suitable entropy source, not change the library itself.
- bmm6o 12y ago
  > This isn't an unusual practice. I would even say it's common within programs that generate random sets, but that those use cases make up a tiny minority of all the uses of rand(), and it shouldn't be difficult to determine them from context.
fryguy 12y ago
Why are things like Mersenne Twister or linear congruential generators platform dependent? To me, there are three classes of reasons you would need random numbers: 1. Simulation. Things like Monte Carlo. In this case, only the statistical quality of the numbers matters. 2. Repeatable simulation. Things like fuzzing tests or benchmarks, where you want them to be repeatable. In this case, you care about determinism and the statistical quality of the numbers. 3. Resource allocation. In this case, you have a set of things that you want to be unique, but to either make them unpredictable (process numbers, invoice numbers) or unique without sharing state (guids). You care about the statistical quality and unpredictability here. The problem is that 2 and 3 are at odds with each other. 3 requires a constant source of entropy, and 2 requires there to be no entropy. I think the following slides are relevant: http://www.openbsd.org/papers/hackfest2014-arc4random/mgp00001.html http://www.openbsd.org/papers/hackfest2014-arc4random/mgp000...
- nitrogen 12y ago
  I would add a #4: cryptography. You don't need to add entropy for #3. If a CSPRNG with n bits of initial entropy as a seed can satisfy #4, then it's also good enough for #3.
  - fryguy 12y ago
    My understanding is that the way cryptography is done is by having hardware entropy source in the CPU fed into some sort of hashing algorithm. Having a CSPRNG with only n bits of initial entropy either exposes the problem of if an attacker can somehow get the state of the CSPRNG, then they can predict future random numbers that are generated (and previous ones, depending on implementation). Constantly reseeding with entropy means that it's not possible to do that.
- bmm6o 12y ago
  I meant that "true" random numbers are platform dependent.
needs 12y ago
It's in fact half of a feature, because the generation method is not specified. So you can't use it for terrain generation in portable code, for example.

by bmm6o 12y ago

kevin_thibedeau 12y ago

I use the determinism with test cases generating random input data. Every run of a test case generates a random seed based off the system time and reports the seed used. When a failure happens, the seed is fixed using an environment variable. Then the failed case can be reproduced until the bug is tracked down. This isn't an unusual practice. The determinism in standard PRNG functions is an important feature not a weakness. Theo is being foolish. If he's unhappy with the way the *rand functions are being used he should just change the code calling into the library to use random seeds derived from a suitable entropy source, not change the library itself.

bmm6o 12y ago
> This isn't an unusual practice. I would even say it's common within programs that generate random sets, but that those use cases make up a tiny minority of all the uses of rand(), and it shouldn't be difficult to determine them from context.

fryguy 12y ago

Why are things like Mersenne Twister or linear congruential generators platform dependent? To me, there are three classes of reasons you would need random numbers: 1. Simulation. Things like Monte Carlo. In this case, only the statistical quality of the numbers matters. 2. Repeatable simulation. Things like fuzzing tests or benchmarks, where you want them to be repeatable. In this case, you care about determinism and the statistical quality of the numbers. 3. Resource allocation. In this case, you have a set of things that you want to be unique, but to either make them unpredictable (process numbers, invoice numbers) or unique without sharing state (guids). You care about the statistical quality and unpredictability here. The problem is that 2 and 3 are at odds with each other. 3 requires a constant source of entropy, and 2 requires there to be no entropy. I think the following slides are relevant: http://www.openbsd.org/papers/hackfest2014-arc4random/mgp00001.html http://www.openbsd.org/papers/hackfest2014-arc4random/mgp000...

nitrogen 12y ago
I would add a #4: cryptography. You don't need to add entropy for #3. If a CSPRNG with n bits of initial entropy as a seed can satisfy #4, then it's also good enough for #3.
- fryguy 12y ago
  My understanding is that the way cryptography is done is by having hardware entropy source in the CPU fed into some sort of hashing algorithm. Having a CSPRNG with only n bits of initial entropy either exposes the problem of if an attacker can somehow get the state of the CSPRNG, then they can predict future random numbers that are generated (and previous ones, depending on implementation). Constantly reseeding with entropy means that it's not possible to do that.
bmm6o 12y ago
I meant that "true" random numbers are platform dependent.

needs 12y ago

It's in fact half of a feature, because the generation method is not specified. So you can't use it for terrain generation in portable code, for example.