Re: rand(), mt_rand() and limits

I fail at reply to all. On 12 January 2015 at 16:52, Leigh <leight@gmail.com> wrote: > On 12 January 2015 at 09:31, Andrea Faulds <ajf@ajf.me> wrote: >> - To produce a repeatable sequence of random numbers (works, but only if you and the sole >> user of the global random number generator, which is not guaranteed by any means) >> > > If you're talking about the libc implementation then this is not the > case, the RNG state is not shared between processes. If you mean > across threads / web requests, then yes rand() is not reentrant, > although this is easily fixed by using rand_r() at the cost an > additional uint per thread. (MT is quite a bit more expensive to make > reentrant) > > On 12 January 2015 at 09:37, Andrea Faulds <ajf@ajf.me> wrote: >> - To generate cryptographic keys - a seeded random number generator should NEVER be used >> for this, but because PHP is so lacking in good facilities to obtain random data for cryptographic >> purposes, unfortunately rand() is used more than it should be. rand() is already pretty bad, but the >> existence of srand() makes this a particular problem. Everything shares the same random number >> generator, which makes it worse, as something might seed it and now your key is easily predictable. > > Nobody with any real desire to produce secure cryptographic keys will > use rand() for this. I've mentioned in a previous thread I would like > to see a generic get_random_bytes() function outside of any > cryptography extensions that would fall back through /dev/?random / > CryptGenRandom / MT to get the best possible random for a string of > bytes for a platform in a quick manner, instead of people trying to > loop over mt_rand(0,255) per byte.