Per-process choosing could be problematic

Posted Dec 12, 2014 12:38 UTC (Fri) by epa (subscriber, #39769)
Parent article: OpenBSD routes around POSIX

So what happens when some library calls srand_deterministic() and changes the behaviour for the rest of the program? Or when the main program calls srand_deterministic() and thus affects any libraries it calls?

I want to be able to choose a seed so that I can repeat the same pseudo-random test case I did last time, but that doesn't mean I want any https: requests made by my test code to silently start using a weaker RNG. Partly this can be solved by having an explicit API for stronger random numbers: arc4random() will always be strong, no matter what srand() type things have gone on in the background. But it would also be good to have an explicit API for pseudo-random number generation, ideally with the new seed value returned each time so it can be passed along by the caller.

Per-process choosing could be problematic

Posted Dec 12, 2014 12:57 UTC (Fri) by cesarb (subscriber, #6266) [Link]

> So what happens when some library calls srand_deterministic() and changes the behaviour for the rest of the program? Or when the main program calls srand_deterministic() and thus affects any libraries it calls?

If your program or library uses the rand()/random()/etc family of calls, it's supposed to be able to work fine with a deterministic RNG (after all, that's what you get in non-OpenBSD systems).

The non-deterministic RNG for rand()/random()/etc is a bonus, like ASLR: if your program's security depends on it, you're doing something wrong.