Re: Flaw in commonly used bash random seed method

[Matthijs <thotter () gmail com>]

Hmm looks like I was wrong...
-snip-
/* Returns a pseudo-random number between 0 and 32767. */
static int
brand ()
{
  rseed = rseed * 1103515245 + 12345;
  return ((unsigned int)((rseed >> 16) & 32767)); /* was % 32768 */
}

> From bash-3.1/variables.c lines 1146-1152
-snip-
(copied from http://cer.freeshell.org/renma/LibraryRandomNumber/#LibraryRandomNumber_sec_bash)

altough it returns a number between 0 and 32767, it indeed saves a 32
bit number, so the cycle length of this linear congruential generator
is actually 2^32. So yes, the seed should be 4 bits and the generator
is better then I first tought. Sorry about that, I should have checked
the code a bit more careful.

Still it is a bad idea to use a PRNG in general, and especially an LCG
for password generation.

On 4/4/06, Dave English <dave.english () thus net> wrote:
> In message
> <a260a2190604031256g23cf3645s348f829530982b38 () mail gmail com>, Matthijs
> <thotter () gmail com> writes
>
> > By the way, if the random function can only generate numbers between 0
> > and 32767, won't 2 bytes be enough then? The algorithm will perform a
> > modulo calculation anyway, so 4 bytes won't really add anything. Of
> > course, it is much better then only one byte.
>
> That will depend on whether the state stored between calls to the PRNG
> is only 15-bits, or something larger.
>
> If more state is stored than is enumerated in the result, then the
> generator should have more points on its sequence than 32768 .  In that
> case then, seeding with more than 15 bits would be worthwhile.
>
> I have not looked at Bash myself, to see what it actually does
> --
> Dave English                      Senior Software & Systems Engineer
>                               Internet Platform Development, Thus plc