random password generator

[trt at rti-sel.UUCP]

NEVER TRUST A PASSWORD GENERATOR
The 'randpasswd' program generates too few different passwords.
The version that uses gettimeofday(II) tends to pick one of ~4000.
Thus it is easy prey for the exhaustive search attack.
(The one that uses getpid(II)/time(II) is more subtly flawed.
Except it has a huge flaw if '-w' is omitted!)
I suppose this sounds like an attack on randpasswd (sorry),
but actually it is a flame against UNIX programs which
purport to generate unguessable random numbers (dice rollers,
card shufflers, rogue, and so on.)

Randpasswd seeds the random number generator
with the tv_usec (microseconds) returned by gettimeofday(II).
Alas, since the VAX has a 100HZ clock tv_usec only takes on
one of 100 values!  Actually, randpasswd calls gettimeofday
several times so the various tv_usec may differ (but rarely by much).

PSUEDO FIXES
Randpasswd could be beefed up by replacing references to tv_usec with
	tv_usec ^ tv_sec ^ getpid()	/* '^' is exclusive or */
but that has its problems too.  For example, if I used it to
determine my password a Bad Guy could look at the modification time
of /etc/passwd (or look at my file access times or run 'lastcomm')
to get a good guess for the time (tv_sec) at which I ran randpasswd.
The process id (getpid) can be similarly guessed.
Indeed almost anything randpasswd might try to use for a seed
can be second guessed by a Bad Guy.

A PROPOSED FIX
Arcade video games use response times as a source of randomness,
often using a rapidly incrementing counter rather than a real clock.
This can be done on UNIX by asking the user to press <INTERRUPT>
and then madly incrementing a counter until the interrupt comes in.
That is probably good for at least 10 low-order bits of randomness,
so to get a thirty-bit random number this should be done three times.
(If the "user" above is actually an anti-random program written
by a Bad Guy then extra care is needed to ensure a random count.)
I know it sounds bizarre, but what else is there?

OTHER FIXES
Randpasswd could be made to work if it had access to a source
of unguessable numbers.  Real microseconds (1e6 of them) would help.
Or new system call that returned a true random number
(implementation to be left up to the kernel/hardware people).
A syscall (or setuid program) that returned the non-reversible
encryption of a secretly maintained sequence number would also do it.
(Keeping the sequence number secret is a major problem.)

	Tom Truscott