Date: Thu, 1 Sep 2005 21:36:53 +0400 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: Using john des routines for 3des (or straight des) cracking On Thu, Sep 01, 2005 at 03:27:13PM +0200, dvorak wrote: > - Is there a reason in the LM cracker for setting the plain text > everytime again? Are you referring to the 64 assignments at the beginning of DES_bs_crypt_LM()? If so, I do not see a way to do it obviously better. I could unroll the loop further such that the first DES round (of 16) would be implemented with its own piece of code and then I could hardcode the input block into its S-box invocations, essentially dropping some XORs completely and replacing the rest with NOTs. This would save the 64 assignments and 41 XORs, for a total of 105 operations. But loop control logic would become slightly more complicated and DES_bs_crypt_LM() would become almost 1.5 times bigger, likely resulting in an overall slowdown on most current systems. > I see that the storage space is re-used to safe > temporary values for the calculations, The code simply keeps the current DES block in the same array. > is this for cache reasons or > merily to prevent having to write rounds(8) number of different s1..s8 > blocks ? Both (referring to L1 instruction cache here). > Or is the resetting an insignificant portion of the time. Yes. > - Is it correct that the key setup for the LM hashes is some kind of > efficient implementations that just sets the correct bits in the > DES_bs_all.K array? Yes. > It seems to be based on only restting the bits that are changed > between old and new + some quick fixes to make all the passwords > uppercase. Correct. > - What is the significance of the DES_BS_VECTOR it seems one round > uses the full mmx register width already, is this a cache optimazation? No. > If so why is it always 2 for mmx? or is there some other reason > entirely? DES_BS_VECTOR, when non-zero, is set to the number of ARCH_WORDs that form the bitslice implementation's vectors. With MMX, the C code uses 32-bit ARCH_WORDs, whereas the native (MMX) vectors are 64-bit, hence DES_BS_VECTOR is set to 2. Similarly, for AltiVec and SSE it is set to 4. For PA-RISC with huge L1 caches, it is currently set to 8, although the vectors are virtual, -- everything is done on plain individual ARCH_WORDs, but the compiler and the CPU are given more parallelism to exploit in this way resulting in a slight speedup. For real vector computers, DES_BS_VECTOR may be set to large values (e.g., 8192) and the compiler is given a chance to actually produce the appropriate vector instructions out of the C code. -- Alexander Peslyak <solar at openwall.com> GPG key ID: B35D3598 fp: 6429 0D7E F130 C13E C929 6447 73C3 A290 B35D 3598 http://www.openwall.com - bringing security into open computing environments Was I helpful? Please give your feedback here: http://rate.affero.net/solar
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.