On Sun, 2012-01-15 at 18:06 +0100, Bert Huijben wrote: > If you call srand() before every call to rand() the result is no longer > random.
Yes, I'm aware of that. > And in this case we do this inside a shared library, so this might introduce > other attack vectors in applications that use apr. Also aware of that. > If we really want to call srand() from apr we should do that from a one-time > initialization (apr_initialize? Or some initialize flag), to avoid breaking > applications that assume rand() produces random values for them. Calling > srand() from apr_hash_make might even break scientific applications that want > the same set of random values multiple times (srand(CONSTANT)). We can call srand() once as you suggest, but that doesn't mean something else isn't going to call it from some other thread at any point. Relying on rand() returning predictable values in a multi-threaded app would be naive anyway. > If the timer has enough detail we could just use the time, ptr combination as > the seed here. This is essentially what the code does by calling srand() > every time anyway. That is true. In fact, my first code to the list just used ht. We could use ht and time to get "random" values. Same attack vectors as noted by you above apply, of course. -- Bojan
