`Hi,There appears to be an error in how random seeding is done in therandom32.c RNG. I am looking at 2.6.25.7.For background, that file contains this comment:"""        ... the k_j most significant bits of z_j must be non-        zero, for each j. (Note: this restriction also applies to the        computer code given in [4], but was mistakenly not mentioned in        that paper.)   This affects the seeding procedure by imposing the requirement   s1 > 1, s2 > 7, s3 > 15."""The function random32_reseed takes an unsigned long's worth of entropyfrom the entropy pool (get_random_bytes) and passes it to__set_random32.  That function (seemingly attempts) to impose therequirement mentioned above by first checking if the seed is == 0, andif so setting it to one, then setting s2 to s*69069 and s3 to s2*69069However this will allow bad seeds. On 64-bit systems, if the low order32 bits of the seed are zero, then the check for s == 0 will pass, buts1, s2, and s3 will all be initialized to zero due to truncation. Thiswill, since there are no additive factors in the RNG sequence, causethe RNG to output nothing but zero values. Assuming get_random_bytesreturns uniform random numbers, this will occur with probabilityaround 1/2^32.An easy and straightforward fix for this that doesn't require changingany interfaces is to add  s &= 0xFFFFFFFF;before the check in __set_random32, which ensures this condition willbe caught by the check. Alternately, you could replace the check fors == 0 with some logic like:  if((s & 0xFFFFFFFF) == 0)     s += 1;since just chopping the seed to 32 bits does throw away some of yourseed input (with sizeof(long) == 8, at least; doesn't make anydifference for sizeof(long) == 4)There are also many other seeds which will cause some (but not all) ofthe seeding requirements to be violated. Which seeds will cause thisproblem depend on the size of unsigned long, since the multiplicationsby 69069 are done in that size.For instance on 32-bit systems, a seed of 0x4BC54E0A will generatethe state:  s1 = 0x4BC54E0A  s2 = (s1 * 69069) % 2^32 = 2  s3 = 2*69069 = 138138In general, there seem to be large numbers of seeds that cause atleast one of the restrictions on s1, s2, s3 to be false. The paperreferenced in the source is not clear exactly how badly the generatorfails when only one of the restrictions is violated. Certainly itseems much less serious than the 64-bit specific bug described above;which is fortunate since it seems to occur much more often. A trivialpatch for both problems is attached.Please Cc: me on any replies as I am not subscribed to the list.Jack--- random32.c.orig     2008-06-19 11:21:57.000000000 -0400+++ random32.c  2008-06-19 11:23:05.000000000 -0400@@ -58,13 +58,17 @@  static void __set_random32(struct rnd_state *state, unsigned long s) {+       s &= 0xFFFFFFFF;        if (s == 0)                s = 1;      /* default seed is 1 */  #define LCG(n) (69069 * n)        state->s1 = LCG(s);+       if(state->s1 < 2) state->s1 += 2;        state->s2 = LCG(state->s1);+       if(state->s2 < 8) state->s2 += 8;        state->s3 = LCG(state->s2);+       if(state->s3 < 16) state->s3 += 16;         /* "warm it up" */        __random32(state);`