prng change feedback

[Harald Welte]

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