tstorm@vu44.UUCP (Theo van der Storm) (08/20/85)
In article <4958@allegra.UUCP> don@allegra.UUCP (Don Mitchell) writes: >There is no bug in libc/gen/crypt.c. The array E is generated from the >permutation in array e. This is the "salting" opperation. Not exactly. 1) The array e is copied to array E. 2) The "salting" operation is the change of the E array. You MUST do 1) and you CAN do 2). Crypt() does both. This means that the function crypt() is OK, but the library also provides the functions setkey() and encrypt() in libc/gen/crypt.c. The manual suggests you can use these functions to encrypt 64 bit blocks with 56 bit keys. If you use them this way however, the array E is not generated at all! (1) is not done.) This is what I tried to point out in my previous article. A second remark about libc/gen/crypt.c is that it accesses the array R by L[32], L[33] ... L[63]! Declaration: static char L[32], R[32]; >Cryptography is a field that has no room for hacking. I would not make >an uneducated change in the DES algorithm and then think it will be >more secure. I apologize for posting an incorrect "Fix" in my previous article, but I cannot help thinking the original implementation was the result of a hacking party. I suggest the following fix: Move the lines for(i=0;i<48;i++) E[i] = e[i]; from the function crypt() to the function setkey(). -- Theo van der Storm, 052 19'08"N / 004 51'16"E UUCP: {seismo|decvax|philabs}!mcvax!vu44!tstorm UUCP: {ark|botter|klipper|tjalk|vu45|vu60}!vu44!tstorm
peter@baylor.UUCP (Peter da Silva) (08/23/85)
OK. The documentation on 4.2 crypt doesn't mention DES. I seem to remember
reading in some security paper somewhere that crypt used a deliberately
flawed version of DES so DES chips couldn't be used for a fast exhaustive
search. Anyone actually have the paper involved (I read it in a manual
rack on the 5th floor of Evans while waiting for printout), so they can
confirm or deny this vicious rumor?
--
Peter (Made in Australia) da Silva
UUCP: ...!shell!neuro1!{hyd-ptd,baylor,datafac}!peter
MCI: PDASILVA; CIS: 70216,1076simsong@mit-amt.MIT.EDU (Simson Garfinkel) (08/25/85)
In article <517@baylor.UUCP>, peter@baylor.UUCP (Peter da Silva) writes: > OK. The documentation on 4.2 crypt doesn't mention DES. I seem to remember > reading in some security paper somewhere that crypt used a deliberately > flawed version of DES so DES chips couldn't be used for a fast exhaustive > search. Anyone actually have the paper involved (I read it in a manual > rack on the 5th floor of Evans while waiting for printout), so they can > confirm or deny this vicious rumor? > -- crypt(2) and crypt(1) are different. crypt(2) is an itterated and defective DEA (software DES) implementation that takes a string key and a 2 character salt and returns those familar passwd-like encrypted strings. It is indeed not true DES so that you can't use a DES chip to braek passwords. This is explained in detail in /usr/doc/password. crypt(1), the 4.2 crypt program, uses DEA to generate a key sequence. It then throws away the security of DEA and uses an enigma-like rotor-based encryption scheme to cipher the rest of the plaintext. (actually, the system that crypt(1) uses is less secure than enigma.) DEA may or may not be secure. crypt(2) is definately secure, but it is one way. crypt(1) is insecure (it can be broken programatically). Hope this clears things up. (Of course, If I've made a mistake, I'm sure I'll be told about it).
smb@ulysses.UUCP (Steven Bellovin) (08/26/85)
> OK. The documentation on 4.2 crypt doesn't mention DES. I seem to remember > reading in some security paper somewhere that crypt used a deliberately > flawed version of DES so DES chips couldn't be used for a fast exhaustive > search. Anyone actually have the paper involved (I read it in a manual > rack on the 5th floor of Evans while waiting for printout), so they can > confirm or deny this vicious rumor? The paper is "Password Security: A Case History", by Thompson and Morris. It's in the 4.2 documentation, and was also published in CACM, November, 1979. The paper is well worth reading if you're at all interested in password security.