karn@faline.bellcore.com (Phil R. Karn) (01/27/88)
I assume you're referring to the technique I described. I was well aware that its effectiveness depends entirely on the resistance of the cipher function (DES, in this case) against known-plaintext attack. DES is supposed to have this property. All of the attacks I've seen discussed in the literature assume knowledge of a plaintext/ciphertext pair. As far as anyone has admitted in the open literature, there is no way to find the corresponding key in this case other than by trying keys until one works. Phil
dnelson@ddsw1.UUCP (Douglas Nelson) (01/28/88)
I saw an interesting program used by hackers on Unix in order to hack away at passwords encrypted in the /etc/passwd file. Basically the program took a plaintext word from the /use/dict/words file, a large spellcheck dictionary found on most System V/BSD/Etc sytems anymore, crypted the plaintext (using crypt() ) the compared it using strcmp against the password field in the /etc/passwd file. Seemed quite effective if your passwords were standard plaintext english words. What exactly is the fate of the standard DES encryption method? I am a person that has very little knowledge of DES or encryption, but have a growing interest. From my understanding it was dropped as the national standard, and a new chip-type of encryption method is going to be used(?) Any help to my ignorant mind would be greatly appreciated...! ------------------ Douglas Nelson dnelson@ddsw1.UUCP ------------------
ln63wgq@sdcc13.ucsd.EDU (Keith Messer) (01/29/88)
That's a very interesting problem: You have a 64 bit key, 56 bits of which are being used in the encryption. There is a known 64 bit plaintext and a known 64 bit cyphertext. We must assume that IBM worked things out so a large number of plaintexts are not mapped into the same cyphertext with different keys, lest key searching be easier than it already is. So... There >is< a way to narrow the key search down to within a few orders of 255 possibilites (the 8 bit mandatory gap between the number of possible keys and the number of possible cyphertexts). I'm trying to work out a method now for making assertions about the intermediate stages of the algorithm (1 of 16 s-box XOR steps back, for instance). A correct "guess" about information in the intermediate steps will give you a 33% knowledge about the key because of key selection (33% is from memory & may be incorrect). My really big problem right now is not the s-boxes which everyone talks about as being the big strong point of des, but the XOR's. Anyone who's thought about this, >please< leave me mail or post here. I feel fairly close to figuring this thing out, and have been working out single-table solutions to the iterative part of the code (there is an excellent paper published on the subject, which I will site when I can find it). Does anyone see big faults with this line of reasoning? Keith Messer ln63wgq@sdcc13.ucsd.edu "The NBS comittee members who decided to use 56-bit instead of 128-bit keys for the DEA should be set on fire." -- Me