4 ms·

> they made rand actually random That is a phenomenally stupid thing to do. There is legitimate need for reproducible pseudo-random sequences derived from a kn

> they made rand actually random That is a phenomenally stupid thing to do. There is legitimate need for reproducible pseudo-random sequences derived from a known random seed. If you break seeding that can't be done. This is how fuzz testing with generated inputs works.

twic 2y ago
The spec [1] only requires that the sequence of pseudo-random numbers is repeated for a given seed within a single process ("subsequent" and "is then"). That means rand as specified is useless for reproducible sequences in fuzzing and so on. So, programs which do that already need to supply their own random number generators, and are not affected by this change. Whereas lots of programs use rand as a source of general-purpose random numbers, but get the seeding wrong, and so suffer from various problems. This change fixes those programs. [1] https://pubs.opengroup.org/onlinepubs/009696699/functions/rand.html https://pubs.opengroup.org/onlinepubs/009696699/functions/ra...
- aidenn0 2y ago
  That's an interesting way to read the specification, seems contrary to the intent and differs from how historic unix systems have implemented it. The author of the man page also disagrees with you on it being allowed by the standard ("If the standardized behavior is required srand_deterministic() can be substituted for srand()..."). Fucking things up for people who understand how PRNGs work just to fix things for people who don't seems backwards; things like this is why configure scripts take over a minute to run. I might be okay with the non-determinism in rand() if srand isn't ever called, but intentionally ignoring the stated intent of the program just pisses me off.
  - kbolino 2y ago
    > non-determinism in rand() if srand isn't ever called This is the path Go took for its math/rand library eventually: if you don't seed the RNG, it's a CSPRNG, but if you do seed it, it's deterministic. However, there is lots of "advice" out there to seed your RNG with "random" values like the current time to make it "more secure" (and to be fair, in some cases, you may get sufficient entropy for the purpose at hand by doing this, but in most cases, you won't get enough and you'll spend it very fast). So a call to srand may indicate that you know what you're doing and want determinism and understand the consequences, but it doesn't necessarily mean that.
    - cpeterso 2y ago
      > seed your RNG with "random" values like the current time Good point. srand(time(NULL)) is a common, yet nondeterministic, seed. The caller clearly doesn't expect rand() to generate a particular sequence of numbers, so srand() could check whether the given seed looks like a time_t close to the current time() and, if it does, then use a proper CSPRNG instead.
      - leni536 2y ago
        That's a horrifying suggestion.
        kbolino 2y ago
        Since any good solution would start with deleting rand and srand from the C standard library entirely, but that's never going to happen, we only have not-good solutions to consider.
    - __s 2y ago
      Amusingly in go 1.24 they're turning srand into a nop: https://github.com/golang/go/issues/67273 https://github.com/golang/go/issues/67273
  - twic 2y ago
    The spec itself contains an informative section which says: > The following code defines a pair of functions that could be incorporated into applications wishing to ensure that the same sequence of numbers is generated across different machines. And then gives code which does not use rand/srand. The intent of the spec is very clearly not for it to be portably reproducible.
crdrost 2y ago
That is a legitimate need, but it should not be the default. Another example of when you need it, is games. I want to store in the game state, that on Day 32 of being in this cave, there is randomly a cache of diamonds if you mine the east wall. If I generate this random number dynamically, then I permit save-scumming behaviors which may distract from the artistic points of my game. So I basically want a random seed and a hash function, hashing (seed, day, activity, location, attempt_number) to see if something is successful.
kbolino 2y ago
Yes, there is a legitimate need, and when you know you need it, you have already demonstrated you know what you are doing, and therefore can find the proper tool, even if it's not the default. Whereas, when you don't know what you're doing, the default should not be a footgun.
- kevin_thibedeau 2y ago
  C has a standard library with known guarantees. Pulling the rug on those guarantees is irresponsible. The appropriate solution is to not break anything and use tooling that flags use of banned symbols that can have negative safety or security implications.
  - kbolino 2y ago
    The problem is not that OpenBSD doesn't follow the standard, it's that the standard is wrong. The default random number facility should be cryptographically secure. Most developers do not know the difference; giving them a deterministic, somewhat more performant, but completely insecure RNG by default expresses the fallacious assumption that they do. This is not the 1980s anymore, virtually every computer is connected to the Internet, there are hundreds of millions of software developers across the globe across all skill levels, and now we have them using LLMs to contend with as well, such naivete is no longer sustainable.
mystified5016 2y ago
Having your random number generator be deterministic by default is extremely bad. Using a deterministic seed should be the exceptional case. In those cases, they provide deterministic operation under a different set of functions so nobody does anything as stupid as using deterministic RNG as encryption
- Someone 2y ago
  But if you compile some third-party code that doesn’t know of that API change, and then use it, that can lead to disaster. For an example, see the GP post at https://news.ycombinator.com/item?id=42971287 https://news.ycombinator.com/item?id=42971287. I think it would have been better to remove rand and srand, and provide two replacement functions with different names, or require all users to pick one using a #define.
somat 2y ago
Yes, and that function goes by several names, I call it the hash function, a deterministic operation that returns unordered results. The non-deterministic variant of this I call random(). if you want deterministic results, you should use the deterministic function.
duskwuff 2y ago
> There is legitimate need for reproducible pseudo-random sequences derived from a known random seed. Correct, but rand() / srand() aren't an effective way of providing for that need. The state of the RNG is process-global; it rapidly becomes nondeterministic in multithreaded applications, let alone if a library you're using calls rand() internally. And, as mentioned upthread, the algorithm is implementation-defined, and isn't guaranteed to remain the same over time.

twic 2y ago

The spec [1] only requires that the sequence of pseudo-random numbers is repeated for a given seed within a single process ("subsequent" and "is then"). That means rand as specified is useless for reproducible sequences in fuzzing and so on. So, programs which do that already need to supply their own random number generators, and are not affected by this change. Whereas lots of programs use rand as a source of general-purpose random numbers, but get the seeding wrong, and so suffer from various problems. This change fixes those programs. [1] https://pubs.opengroup.org/onlinepubs/009696699/functions/rand.html https://pubs.opengroup.org/onlinepubs/009696699/functions/ra...

aidenn0 2y ago
That's an interesting way to read the specification, seems contrary to the intent and differs from how historic unix systems have implemented it. The author of the man page also disagrees with you on it being allowed by the standard ("If the standardized behavior is required srand_deterministic() can be substituted for srand()..."). Fucking things up for people who understand how PRNGs work just to fix things for people who don't seems backwards; things like this is why configure scripts take over a minute to run. I might be okay with the non-determinism in rand() if srand isn't ever called, but intentionally ignoring the stated intent of the program just pisses me off.
- kbolino 2y ago
  > non-determinism in rand() if srand isn't ever called This is the path Go took for its math/rand library eventually: if you don't seed the RNG, it's a CSPRNG, but if you do seed it, it's deterministic. However, there is lots of "advice" out there to seed your RNG with "random" values like the current time to make it "more secure" (and to be fair, in some cases, you may get sufficient entropy for the purpose at hand by doing this, but in most cases, you won't get enough and you'll spend it very fast). So a call to srand may indicate that you know what you're doing and want determinism and understand the consequences, but it doesn't necessarily mean that.
  - cpeterso 2y ago
    > seed your RNG with "random" values like the current time Good point. srand(time(NULL)) is a common, yet nondeterministic, seed. The caller clearly doesn't expect rand() to generate a particular sequence of numbers, so srand() could check whether the given seed looks like a time_t close to the current time() and, if it does, then use a proper CSPRNG instead.
    - leni536 2y ago
      That's a horrifying suggestion.
      - kbolino 2y ago
        Since any good solution would start with deleting rand and srand from the C standard library entirely, but that's never going to happen, we only have not-good solutions to consider.
  - __s 2y ago
    Amusingly in go 1.24 they're turning srand into a nop: https://github.com/golang/go/issues/67273 https://github.com/golang/go/issues/67273
- twic 2y ago
  The spec itself contains an informative section which says: > The following code defines a pair of functions that could be incorporated into applications wishing to ensure that the same sequence of numbers is generated across different machines. And then gives code which does not use rand/srand. The intent of the spec is very clearly not for it to be portably reproducible.

crdrost 2y ago

That is a legitimate need, but it should not be the default. Another example of when you need it, is games. I want to store in the game state, that on Day 32 of being in this cave, there is randomly a cache of diamonds if you mine the east wall. If I generate this random number dynamically, then I permit save-scumming behaviors which may distract from the artistic points of my game. So I basically want a random seed and a hash function, hashing (seed, day, activity, location, attempt_number) to see if something is successful.

kbolino 2y ago

Yes, there is a legitimate need, and when you know you need it, you have already demonstrated you know what you are doing, and therefore can find the proper tool, even if it's not the default. Whereas, when you don't know what you're doing, the default should not be a footgun.

kevin_thibedeau 2y ago
C has a standard library with known guarantees. Pulling the rug on those guarantees is irresponsible. The appropriate solution is to not break anything and use tooling that flags use of banned symbols that can have negative safety or security implications.
- kbolino 2y ago
  The problem is not that OpenBSD doesn't follow the standard, it's that the standard is wrong. The default random number facility should be cryptographically secure. Most developers do not know the difference; giving them a deterministic, somewhat more performant, but completely insecure RNG by default expresses the fallacious assumption that they do. This is not the 1980s anymore, virtually every computer is connected to the Internet, there are hundreds of millions of software developers across the globe across all skill levels, and now we have them using LLMs to contend with as well, such naivete is no longer sustainable.

mystified5016 2y ago

Having your random number generator be deterministic by default is extremely bad. Using a deterministic seed should be the exceptional case. In those cases, they provide deterministic operation under a different set of functions so nobody does anything as stupid as using deterministic RNG as encryption

Someone 2y ago
But if you compile some third-party code that doesn’t know of that API change, and then use it, that can lead to disaster. For an example, see the GP post at https://news.ycombinator.com/item?id=42971287 https://news.ycombinator.com/item?id=42971287. I think it would have been better to remove rand and srand, and provide two replacement functions with different names, or require all users to pick one using a #define.

somat 2y ago

Yes, and that function goes by several names, I call it the hash function, a deterministic operation that returns unordered results. The non-deterministic variant of this I call random(). if you want deterministic results, you should use the deterministic function.

duskwuff 2y ago

> There is legitimate need for reproducible pseudo-random sequences derived from a known random seed. Correct, but rand() / srand() aren't an effective way of providing for that need. The state of the RNG is process-global; it rapidly becomes nondeterministic in multithreaded applications, let alone if a library you're using calls rand() internally. And, as mentioned upthread, the algorithm is implementation-defined, and isn't guaranteed to remain the same over time.