mailing list archives
Re: Flaw in commonly used bash random seed method
From: Matthijs <thotter () gmail com>
Date: Tue, 4 Apr 2006 16:47:30 +0200
Hmm looks like I was wrong...
/* Returns a pseudo-random number between 0 and 32767. */
rseed = rseed * 1103515245 + 12345;
return ((unsigned int)((rseed >> 16) & 32767)); /* was % 32768 */
From bash-3.1/variables.c lines 1146-1152
(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:
<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