Follow @Openwall on Twitter for new release announcements and other news
[<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.