Re: Flaw in commonly used bash random seed method
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
>
>
>