improve random seed to a slightly more random number #9
Conversation
berthubert
changed the title
| struct timeval tv; | ||
| gettimeofday(&tv, 0); | ||
| // this is not very good, but we lack a portable non-blocking API | ||
| srand( ((unsigned int) tv.tv_usec) ^ (unsigned int)getpid()); |
There was a problem hiding this comment.
I appreciate the problem, and I also value the simplicity. But: on the operating system lending this file its name, there's a non-blocking /dev/urandom. That's not POSIX, but quite the same on Linux, FreeBSD, and as far as I know also MacOS, and its various mutations.
Is there a strong argument for doing a gettimeofday syscall and a getpid syscall to supply low-quality randomness, rather than open, read, and close to get a good seed?
There was a problem hiding this comment.
the key point is "as far as we know". Also this code might be used in places that can't see /dev. The seed is not a secret it just needs to vary a bit. I think this library has chosen to be "something that just works", and then this choice is good enough.
There was a problem hiding this comment.
I see, though I'd like to point out that one of the common places where this kind of time-based seeding fails short is on booting of embedded devices without RTC. E.g., router turns on, takes (down to few milliseconds) exactly the same time to load initrd, boot kernel, launch admin interface, which launches the "first user setup" routine, which hence always ends up with the same time-based seed. I don't know how PIDs are randomized on such a system.
Now, you'll be right to exclaim "but a few milliseconds is still way much variation in µs!", and you'd be very right. But, fun awaits at least under Linux with userland time functions on platforms that don't have a hardware high-res timer register; in many cases, time gets systick-quantized, even on x86_64.
Hence my caveat: I 100% would merge this, it's indubitably an improvement, but for the cases where a non-varying seed is especially problematic, namely, when someone with the same device can reconstruct the same seed, I'm not sure it's a solution :)
There was a problem hiding this comment.
Hi guys,
thank you discussing and supporting this project.
This author did some investigations around that:
https://codingnest.com/generating-random-numbers-using-c-standard-library-the-problems/
It looks like there is not simple way to implement a platform independent solution.
/dev/urandom and gettimeofday would prevent us using the code within MS Windows.
This comment was marked as resolved.
This comment was marked as resolved.
When provisioning new users, I found all user password hashes ended up with the same salt. Turns out this code uses time(0) as a non-blocking random seed. Doing non-blocking good random from 2003 C++ is not easy, so I upgraded the code to use the microsecond component of gettimeofday xored with the pid as the random seed. I also enhanced the test code to hash the same password twice, which shows you the salt is different.