lib/genrand.c weirdness

[Peter Samuelson]

[Andrew Bartlett]
> 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.

The function is not crazy at all if you assume /dev/urandom is not
available, a pretty safe assumption on 95% of the platforms Samba
supports.  The only strange part is that it doesn't drop out early if
/dev/urandom *is* available.

I don't know why it doesn't, but I have heard it said that paranoia
about degree of randomness is often desirable.  As Ted Ts'o puts it,
you are guarding against "catastrophic failure" of one or more sources
-- if it turns out some time in the future that /dev/urandom is
crackable after all, Samba at least does not depend solely on that.

And speaking of /dev/urandom, it may or may not be what you think.
Someone on some Unix system somewhere may provide /dev/urandom as a
pipe with a daemon like egd behind it.  In that case, are you so sure
it is sufficient?

And in a sense, you "may as well" add in those file hashes and
timestamps.  The way crypto hashes like md4 work, no matter how much
non-random seed you throw into the mix, you will end up with *at least*
as much entropy at the other end as you started with, so it cannot hurt
(disregarding efficiency).

> 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?)

What platforms does Samba support where unsigned int is other than 32
bits?  I do not know of any but am willing to be surprised.

Peter