I'm not sure how calling srand every time would help at all, though.
Your point is that there are only 2^32 possible seeds. If we call srand
every time, then there are still only 2^32 possible seeds. In fact,
calling srand every time makes it worse; at least at the moment the
administrator can tell makepasswd to produce some large number of
passwords and select an arbitrary (if not truly random) one from that
list. Since Debian's Perl is configured to use drand48() as its
implementation of rand, there are in fact considerably more than 2^32
passwords available to an administrator following this strategy. Forcing
makepasswd to reset the random seed every time *worsens* the situation
because now there are only 2^32 possible passwords no matter how many
you tell makepasswd to generate at once, because you only ever get the
first value from the PRNG sequence.
No, calling srand function with 32 bit cryptographic secure random number
argument before each rand function call does _not_ make things worse and
number of available passwords is not limited by 2^32.
With this approach first char of password depends on first 4 bytes read
from /dev/urandom. The second char depends on second 4 bytes read from
/dev/urandom. The third char depends on third 4 bytes read from
/dev/urandom. And so on. But! /dev/urandom is based on cryptographic secure
pseudo random number generator so none can easily forecast next bytes given
the previous ones. I think that cryptographic strength of /dev/urandom is
256 bit so number of generated passwords using data from /dev/urandom may
be estimated to be not less than 2^256.
How about we use libcrypt-openssl-random-perl instead? You can seed its
PRNG with an arbitrary amount of data; I expect 256 bits would be quite
adequate given that that's vastly more than the space of available
passwords for the default lengths, and you'd have to be generating
somewhat over 30-character passwords before you started reaching that
kind of entropy. (Plus, urandom(4) recommends reading no more than that
amount of data per invocation.)
I think that using either of libcrypt and /dev/urandom is secure and which
one to choose is just matter of taste. To my taste system internal
cryptographic PRNG (/dev/urandom) is more tested and secure than any third
party library. And it is _already_ used by makepasswd package. So all
required to do is just ignore --rerandom key and fix this parameter value to 1.
On the other hand makepasswd has key
--randomseed=N Use random number seed N, between 0 and 2^32 inclusive.
A zero value results in a real-random seed.
I think that this key should be made deprecated and disallowed at all. But
if it is absolutely necessary to allow creation of predictable (but
secure!) passwords then /dev/urandom cannot help, libcrypt should be used
instead (and range of arguments to --randomseed should be extended to 2^256).
Or for backward compatibility it is possible to use old approach (internal
rand without reseed) if --randomseed argument is specified. Anyway users of
--randomseed were warned that there are only 2^32 cases.
Cheers,
Fyodor Menshikov.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
