On Apr 7 2009, Stacey Jonathan Marshall wrote:
On 04/06/09 16:06, Chris Thompson wrote:
It turns out that rand(3c) in even recent Solaris versions returns
values in the range 0..32767 only. I suppose this is part of Sun's
rather extreme paranoia about backwards compatibility with programs
written before the flood.
rand(3C) - simple random-number generator returns successive
pseudo-random numbers in the range of 0 to RAND_MAX (defined as 32767).
Yes, it's documented - I should perhaps have said that.
However, RAND_MAX on some other Unix-flavoured systems (including some,
but apparently not all, Linuxes) is 0x7FFFFFFF so that one gets random
31-bit numbers rather than 15-bit ones. It seems that the writers
of BIND's lib/isc/random.c were assuming that (the comments go on
about the top bit being 0 and the bottom bits less random).
BIND 8 was changed to use /dev/urandom on Solaris around the time when
arc4random() was added to it.
Perhaps a similar solution could be used here?
I'm not quite sure what you are suggesting here. BIND needs (fast)
weak pseudo-random numbers as well as (slow) cryptographically strong
ones. The routines in lib/isc/random.c can get hot, e.g. if they
are used to randomise the order that RRsets are returned in responses.
I don't think one would want to use /dev/urandom there (except to
seed the generator, perhaps).
--
Chris Thompson
Email: c...@cam.ac.uk
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
