[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a260a2190604031256g23cf3645s348f829530982b38@mail.gmail.com>
Date: Mon, 3 Apr 2006 21:56:12 +0200
From: Matthijs <thotter@...il.com>
To: coderpunk <coderpunk@...il.com>, bugtraq@...urityfocus.com
Subject: Re: Flaw in commonly used bash random seed method
I hope nobody generates passwords with ANY kind of pseudo-RNG. No
matter how good those algorithms are (and linear congruential
generators, the algorithm type of the bash function, usually aren't
very good), the results can be reproduced. Therefore you shouldn't
really generate your passwords with it IMHO. The short cycle length of
this algorithm only makes it worse.
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.
On 4/2/06, coderpunk <coderpunk@...il.com> wrote:
> I think I just discovered a flaw in what appears to be a common way to
> see bash's $RANDOM function. bash provides a pseudo-random number,
> from 0-32767, using the $RANDOM function. You can seed this by setting
> RANDOM=42 or some other number. Otherwise it is seeded by the process
> id and time.
>
> There are a plethora of usenet and web posts that suggest using the
> following to seed the function:
> SEED=$(head -1 /dev/urandom | od -N 1 | awk '{ print $2 }')
>
> But look at the output, and the manpage for od. All this is doing is
> reading 1 line of /dev/urandom (a binary stream), passing it to od
> which is taking 1 byte and converting it to octal and printing it with
> awk. What's wrong with this picture? You've just taken a random source
> and turned it into a number from 0-255!
>
> I hope you haven't been generating your password lists with any of the
> scripts using that seed method.
>
> Here is a better way:
>
> SEED=$(head -c4 /dev/urandom | od -t u4 | awk '{ print $2 }')
>
> This reads 4 bytes from /dev/urandom, passed it to od which converts
> it into a unsigned 4 byte integer and prints it. This should have a
> range of 2**32 (4294967296L) which is a bit more secure than 0-255.
>
> .cp
>
Powered by blists - more mailing lists