Hi RS,
After running the above tests and reading the related documentation, my conclusion is that it would be reasonable to use syscall(SYS_getrandom, &buf, bufsize, 0) as a suitable replacement for rand() in all cases without any concrete security or performance concerns. The overhead is also significantly less than importing or otherwise depending on OpenSSL, GnuTLS, NaCL, or probably even glibc.
Thanks again for your investigation.
So the conclusion is probably, for now: * use getrandom() with zero flags for TMSIs and other random identifiers * use getrandom() with zero flags for RAND challenges * use getrandom() with GRND_RANDOM flag for K/OP/OPc/Ki generation
It may make sense to use the platform's libc interface if it is available.
I would go for that, and I believe the current patch under discussion is doing exactly that: use getrandom() if available, and fall back to the raw syscall, if not.
Further falling back on rand() is probably a bad idea, we could simply make this a fatal runtime error ending the program and see if anyone ever reports that error to the mailing list. If at all, the fall-back should not happen automatically, but should be explicitly requested at compile-time ("--enable-unsafe-rand"), or depend on an environment variable, or the like. Basically to make sure the default configuration will be safe, and any unsafe operation requires explicit user intervention.
It may also be worthwhile to try to ensure that buffer is indeed changed.
good point, I like that.
The small program below could also easily be modified to test that the buffer is indeed completely filled with some new data and to additionally hash the buffer before use in any cryptographic application.
Yes, we could improve on that by using some hashing function on the result, rather than using the (cs)prng output directly. But let's keep that as a possible future improvement for now. Out of curiosity: What would you recommend?
Regards, Harald