[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20050901173653.GA5203@openwall.com>
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.
