Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83 (MC840302); site vu44.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!mcvax!vu44!tstorm
From: tstorm@vu44.UUCP (Theo van der Storm)
Newsgroups: net.bugs.4bsd,net.bugs.v7,net.crypt
Subject: /usr/src/libc/gen/crypt.c, DES
Message-ID: <682@vu44.UUCP>
Date: Fri, 16-Aug-85 11:21:23 EDT
Article-I.D.: vu44.682
Posted: Fri Aug 16 11:21:23 1985
Date-Received: Tue, 20-Aug-85 05:59:53 EDT
Distribution: net
Organization: VU Informatica, Amsterdam
Lines: 43
Xref: watmath net.bugs.4bsd:1689 net.bugs.v7:203 net.crypt:434

In DES, an iteration looks like this: (Li and Ri are 32 bit numbers)
    Li =  Ri-1
    Ri =  Li-1 XOR f(Ri-1, Ki)

Question 1:
Does anyone know what the consequences are for the security of
the encryption if f(Ri-1, Ki) is replaced by f(Li-1_31, Ki), where
Li-1_31 is the last bit of Li?
    Li =  Ri-1
    Ri =  Li-1 XOR f(Li-1_31, Ki)

Obviously, the contents of L and R remain separated throughout
all iterations. On the other hand, the key Ki is fully
effective for both L and (the next) R.

I am asking this, because I found the following bug? in
/usr/src/libc/gen/crypt.c (both 4.1BSD and Version 7)

BEGIN QUOTE
static char L[32], R[32];
END QUOTE
BEGIN QUOTE
static	char	E[48];
static	char	e[] = {
	32, 1, 2, 3, 4, 5,
END QUOTE
BEGIN QUOTE
		for (j=0; j<48; j++)
			preS[j] = R[E[j]-1] ^ KS[i][j];
END QUOTE

'L' and 'R' contain 32 bits each (one bit/byte).
'E' contains only null bytes, 'e' containes a permutation,
but it is never used.
Fix:
Delete "static char E[48];" and replace "e[]" on the next line by "E[]".

Question 2:
Is somebody fooling me or is this real?
-- 
	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