Password encryption

[John Franks Dept. of Math. Northwestern Univ.]

In article <13022 at bellcore.bellcore.com>, karn at ka9q.bellcore.com (Phil Karn) writes:
> >>                          I'd also like to see a standard "key crunching"
> >> algorithm for transforming a password (or phrase) longer than 8 characters
> >> into a 56-bit DES key.
> 
> The point is that to be maximally effective, the UNIX password
> algorithm should be given keys with 56 bits of entropy. That is, the
> distribution of actual user keys should be uniformly distributed over
> all 2^56 possible values.
> 

I agree with this completely.  This is a much better solution than
a hidden passwd file.  

Also I don't believe that the two short words separated by  punc-
tuation  is  really very secure.  For most people this would be a
password of the form  "3-letter-word ? 4-letter-word",  (where  ?
is  a  punctuation  character) or  the same form with the 3 and 4
letter words switched.  My /usr/dict (SunOS 4.0) has 775 3-letter
words  and 2152 4-letter words.  If we say 20 punctuation charac-
ters, that gives a password space with 2*775*20*2152 = 66,712,000
possibilities.   If  1000 encryptions per second is possible then
the whole space can be done in something over 18 hours.

Question: Why are we limited to 56 bits?  Surely  not  for  effi-
ciency  or to save space.  This is an instance where we *want* to
be slow.  I've heard that NSA lobbied for smallish keys  in  com-
mercial  DES  rather than larger ones (the implication being they
wanted a  size they  could handle easily).  Does  anybody know if 
there is any truth to this?




























































-- 
John Franks 	Dept of Math. Northwestern University
		Internet	john at math.nwu.edu
		Bitnet		j_franks at nuacc