john@rufus.math.nwu.edu (John Franks Dept. of Math. Northwestern Univ.) (12/30/88)
In article <13022@bellcore.bellcore.com>, karn@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@math.nwu.edu Bitnet j_franks@nuacc