[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150703043807.GA18809@openwall.com>
Date: Fri, 3 Jul 2015 07:38:07 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: LM and halves, length limit, does john "attack" halves together?
On Thu, Jul 02, 2015 at 11:40:54PM +0300, Aleksey Cherepanov wrote:
> I'd like to know how john handles candidates in relation to halves of
> LMs?
You've already found the "x**" rules. This is how.
> Let's consider "Password1" password. There will be 2 LMs with
> passwords: PASSWOR and D1 . Does john know that first 7 chars should
> be cut off? I don't see that in code.
DES_bs.c: DES_bs_set_key_LM()
> But I see a rule for that:
>
> # Used for loopback. This rule will produce candidates "PASSWOR" and "D" for
> # an input of "PASSWORD" (assuming LM, which has halves of length 7).
> [List.Rules:Split]
> :
> -s x**
>
> I find "Used for loopback" misleading because john (jumbo) stores
> truncated passwords in .pot.
The rule does make sense for loopback attack in case someone had cracked
NT hashes first, and is now cracking LM. A weird thing to do, but I
guess it does happen. It is also relevant for common passwords in
general, not necessarily coming from the same accounts.
> The rule is for original attack and it should be combined with other
> rules.
There are instances of this rule in Single and Wordlist as well.
> Would not it be more convenient to do that in format itself?
Until recently, the format could only test candidates that were given to
it (maybe mangling them first as part of the format's key setup: e.g.,
truncate at 7 and uppercase for LM), not produce additional candidates.
The ability for a format to produce additional candidates has recently
been added, but I think it's not a good fit for LM's halves because the
halves are only produced for input candidate lengths of 8 and higher
rather than in all cases. Thus, the number of candidates to hash in
crypt_all() would frequently deviate from being a multiple of the
bitslice DES vector depth, resulting in suboptimal c/s rate. (And yes,
this becomes closely related to the "continuous feeding" problem you
brought up on john-dev recently.)
Alexander
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.
