Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!mgnetp!ihnp4!zehntel!dual!amd!decwrl!decvax!mcnc!rti!rti-sel!trt
From: trt@rti-sel.UUCP
Newsgroups: net.unix-wizards
Subject: Re: random password generator
Message-ID: <1158@rti-sel.UUCP>
Date: Thu, 2-Aug-84 17:57:02 EDT
Article-I.D.: rti-sel.1158
Posted: Thu Aug  2 17:57:02 1984
Date-Received: Sun, 5-Aug-84 05:18:20 EDT
References: rdin2.110
Lines: 49

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 
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