Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!pasteur!ucbvax!hplabs!sdcrdcf!randvax!jim From: jim@randvax.UUCP (Jim Gillogly) Newsgroups: sci.crypt Subject: Re: publication status of DES algorithm / NSA Message-ID: <315@markle.randvax.UUCP> Date: 29 Feb 88 16:11:33 GMT References: <934@PT.CS.CMU.EDU> <770@entropy.ms.washington.edu> <7343@brl-smoke.ARPA> Organization: Banzai Institute Lines: 31 In article <7343@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) writes: >In article <770@entropy.ms.washington.edu> martin@entropy.ms.washington.edu (Don Martin) writes: >>A book that is highly recomded in spite of the poor >>implemetation of DES ( 1 bit per integer ). > >Why do you consider that a poor implementation decision? >It's the way I would have done it. Packed bits would be >too slow. It's more fun to keep them in 48-bit words (or 32 if that's all you've got) so that you can do operations on them a word at a time. For the permutations, for example, you can precompute the result of the permutation applied to each byte in each position, and OR them together. The XOR operations happen immediately, of course. Hauling 6- or 12-bit chunks out to stuff through S-boxes (or doubled S-boxes if you have the luxury of lots of memory) is simplified if you're using the 48-bit size, but can be handled with a few shifts and logical operations without much trouble even with 32-bit words. Somebody (Dan Hoey?) posted some useful hacks a few months ago, including an absolutely wonderful way to make the initial and final permutations almost painless using a modification of a HAKMEM algorithm by Rick Gumpertz and himself. These used very fancy shifting and logical ops to do the IP and FP in much less time than the table-lookup stuff that I described briefly above (which still would need to be used for the combined S-P operation). Jim Gillogly -- Jim Gillogly {hplabs, ihnp4}!sdcrdcf!randvax!jim jim@rand-unix.arpa [HASA: U (Spam) division]