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
--
- Harald Welte <laforge(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)