mlm@NL.CS.CMU.EDU (Michael Mauldin) (02/23/88)
Note that the DES algorithm has been published for years. See at "Cryptography and Data Security", Dorothy Denning, Addison-Wesley, 1982. I'm sure there's also an NBS document describing it for sale by the US Government. It's hard to believe that posting C source on UseNet is subtantially different from that. You'd have a hard time defining the difference between an algorithm described by mathematical pseudo-code and C source that just also happens to run on a computer. Of course the NSA reads this newsgroup. But don't expect them to react to it, much. A big part of the business of keeping secrets is not letting other people know what you know. The more they react, the more we'll know about what they worry about. So they'll stay quietly in the background. Just to prove it, here's the source for a DES cracker: ZZZZ 0345 NOTICE 490 LINES REMOVED TO CLASSIFIED FILE DRAWER NBS-D-5712 CONTACT ARMY INFORMATION OFFICE, FT MEAD, MARYLAND. See? ;-) Michael L. Mauldin (Fuzzy) Department of Computer Science ARPA: Michael.Mauldin@NL.CS.CMU.EDU Carnegie-Mellon University Phone: (412) 268-3065 Pittsburgh, PA 15213-3890
martin@entropy.ms.washington.edu (Don Martin) (02/24/88)
One possibilty is to use a foriegn publisher. As an example, both FORTRAN and Pascal DES algorithms are published in: _Numerical Recipes: The Art of Scientific Computing_ Press, Flannery, Teukolsky and Vetterling. Cambridge University Press. A book that is highly recomded in spite of the poor implemetation of DES ( 1 bit per integer ). Actually, I cannot see how a conviction could be obtained given the wide distribution of the DES algorirthm even it it were illegal. I would also be very surprised ( well perhaps a little bit surprised ) if any government agency would dare to set a precedent with DES given the great risk of losing the case. Not to mention becoming known as real idiots. Don Martin martin@entropy.ms.washington.ms
gwyn@brl-smoke.ARPA (Doug Gwyn ) (02/25/88)
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.
martin@entropy.ms.washington.edu (Don Martin) (02/29/88)
Poor was a ill chosen phrase. The Numerical Recipes DES is quite slow but portable by using one bit per iteger. If bit packing were used, then it should be faster. Also, it would be pretty easy to use a variant of the integer algorithm to do 16 or 32 blocks in parallel.
jim@randvax.UUCP (Jim Gillogly) (03/01/88)
In article <7343@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) 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]