Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!brl-tgr!tgr!tstorm%vu44.uucp@BRL.ARPA From: tstorm%vu44.uucp@BRL.ARPA (Theo van der Storm) Newsgroups: net.unix-wizards Subject: /usr/src/libc/gen/crypt.c, DES Message-ID: <790@brl-tgr.ARPA> Date: Mon, 19-Aug-85 03:56:20 EDT Article-I.D.: brl-tgr.790 Posted: Mon Aug 19 03:56:20 1985 Date-Received: Tue, 20-Aug-85 22:39:25 EDT Sender: news@brl-tgr.ARPA Lines: 43 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