Re: Flaw in commonly used bash random seed method

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx> wrote:
> In message
> <a260a2190604031256g23cf3645s348f829530982b38@xxxxxxxxxxxxxx>, Matthijs
> <thotter@xxxxxxxxx> 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
>
>
>


[Index of Archives]     [Linux Security]     [Netfilter]     [PHP]     [Yosemite News]     [Linux Kernel]

  Powered by Linux