lib/genrand.c weirdness

[Andrew Bartlett]

Both Samba and Samba-TNG seem to use the same code for genrand.c and
both appear to do some quite crazy things with their random numbers.

My reading of the code - do_reseed() - is that, upon requiring a new
random seed, samba will (if available) read 40 bytes from /dev/urandom
(good so far), and then go though all sorts of crazy steps to introduce
predictable values into the mix, then goes and md4s the result a few
times.  As the output is only 16 bytes + 32 bits why not just read
sizeof(unsigned int) as the return value (sys_srandom takes one unsigned
int, and this is the only place this part of do_reseed's output ever
goes) and then just read the 16 bytes for the return buffer?  This would
also mean that samba would not waste precious kernel entropy, reading
only as many bytes as required.

Does samba for some reason not trust the kernel to provide sufficiently
random numbers?
(If so, should this be a configure test, letting those with kernel
guaranteed randomness use it?)

This is the function in question, note it gets a little confused at the
bottom about bits and bytes, my reading is that we return 32 bits and 16
bytes.  (BTW, how does this work on 64 bit platforms, as srandom takes
an unsigned int, not necessarily 32 bits long?)

As a minimal change, the bracket from the !got_random test should at
least be moved down below the gettimeofday munging.

Just a few thoughts,
Andrew Bartlett

-- 
Andrew Bartlett
abartlet at pcug.org.au