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