Path: utzoo!mnetor!uunet!husc6!linus!gatech!mcnc!rti!trt
From: trt@rti.UUCP (Thomas Truscott)
Newsgroups: comp.unix.wizards
Subject: Re: 60-second timeout in Unix login
Message-ID: <2057@rti.UUCP>
Date: 23 Feb 88 18:25:05 GMT
References: <10578@brl-adm.ARPA> <721X@jimi.cs.unlv.edu> <465@xios.XIOS.UUCP> <260@aiva.ed.ac.uk>
Organization: Research Triangle Institute, RTP, NC
Lines: 26
Summary: Inefficient encryption algorithms do not improve security

In article <260@aiva.ed.ac.uk>, richard@aiva.ed.ac.uk (Richard Tobin) writes:
> ... The whole point of a good encryption algorithm is to make
> this sort of thing hard by making it slow.  (That didn't stop them
> using register variables in crypt(3), however.  ...)

A good encryption method must be more than slow, it must be
*inherently* slow, to reduce the payoff from brute force attacks.
crypt(3) achieves inherent slowness by iterating DES 20 times
(and by using a modified DES to thwart most chip implementations).

Non-inherent slowness is not a benefit, as the Bad Guy
can simply use a faster implementation for the brute force attack.
As it happens, crypt(3) is extremely inefficient.
Bob Baldwin (baldwin@mit-xx.arpa) has written a plug-compatible
equivalent that is sixty times faster.
Using it, our Gould 9050 can trial-encrypt all of /usr/dict/words
in *one minute* (for a given salt).
Slowing down *other* versions of crypt() does not change this!

For improved security one can use the fast version of crypt()
and iterate 1200 times so that it remains slow.

In summary:  An encryption method should be implemented as efficiently
as possible, yet still be slow.  Adding algorithmic inefficiencies
is no better (indeed is worse) than adding "sleep(1);"
	Tom Truscott