Comment by somat | Hacker News Reader

Comment by somat | Hacker News Reader

ah, the seed, an innocent implementation detail, but many people latch on to this and missuse random as a hash function. The one I remember was this screwball long term archival system from the early 2000's, zipped business archives on cd, the zip files were password protected. with the password being a hash of several factors about the data(unit, date, etc). A little stupid, but not the worst thing I have ever seen. The bad part was the hashing algorithm used, it was perls rand(). When I saw that I was vaguely horrified and a few test's confirmed my fears, the perl rand function would vary across operating systems and even different version of perl would change it. I think they ended up having to keep an explicit database of all the passwords just to have a fighting chance at opening those files later. not that they ever would. no one ever looks at long term records once they are stored.

Anyway, I like how the openbsd folk fixed the old C rand family of functions. they made their seed functions do nothing and tied the generators to a strong kernel random source, that is, they made rand actually random. If your application actually depends on rand as a hash function they provided the old behavior under srand_deterministic(3)

"Standards insist that this interface return deterministic results. Unsafe usage is very common, so OpenBSD changed the subsystem to return non-deterministic results by default."

makes me laugh every time.

http://man.openbsd.org/rand

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

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/ra...

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.

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

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

That's a horrifying suggestion.

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.

Amusingly in go 1.24 they're turning srand into a nop: https://github.com/golang/go/issues/67273

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.

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.

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.

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.

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.

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

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.

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.

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.

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

That's an interesting story, thanks for sharing.

However, it is the reason that (what feels like) every single C function has a footnote, along the lines of "*except on FordBAT OS, where mkdir doesn't create a directory, all floats are inf, and negatives are positive -- because it seemed convenient"

Reply on news.ycombinator.com