crypt 3 is OK, but setkey and encrypt 3 NOT

[Theo van der Storm]

In article <4958 at allegra.UUCP> don at 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