Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 7 Feb 2013 01:42:11 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: NetNTLMv1 and MSCHAPv2

On 1 Feb, 2013, at 4:24 , Solar Designer <solar@...nwall.com> wrote:
> Anyhow, I've attached a patch that tries to speedup cmp_all() by use of
> a bitmap.  This only makes sense when cmp_all() is called multiple times
> per crypt_all()'s actual processing - that is, when cracking two or more
> C/R pairs at once.  There's a check for that in the code.  Moreover, use
> of the bitmap is automatically disabled when the C/R pair count reduces
> to 1.

I noticed the formats are significantly faster in unstable than in bleeding, with 1500 c/r real (Test Suite) runs:

[bleeding-jumbo]$ ../run/john ../test/mschapv2_tst.in -fo:mschapv2 -inc:digits
mschapv2: Note: slow loading. For short runs, try mschapv2-naive instead (using
--format=mschapv2-naive). That version loads faster but runs slower.
Loaded 1500 password hashes with 1500 different salts (MSCHAPv2 C/R MD4 DES [128/128 SSE2 intrinsics 12x])
12345            (u-28-mschapv2)
1                (u-8-mschapv2)
guesses: 2  time: 0:00:00:18 DONE (Thu Feb  7 00:45:18 2013)  c/s: 9246M  trying: 83536777 - 83536784


[unstable-jumbo]$ ../run/john ../test/mschapv2_tst.in -fo:mschapv2 -inc:digits
mschapv2: Note: slow loading. For short runs, try mschapv2-naive instead (using
--format=mschapv2-naive). That version loads faster but runs slower.
Loaded 1500 password hashes with 1500 different salts (MSCHAPv2 C/R MD4 DES [128/128 SSE2 intrinsics 12x])
12345            (u-28-mschapv2)
1                (u-8-mschapv2)
guesses: 2  time: 0:00:00:16 DONE (Thu Feb  7 00:46:18 2013)  c/s: 10402M  trying: 83536777 - 83536784


That's 12.5%. For NTLMv1, it's even worse: 8760M vs. 10402M or 18.7%. It's not a general issue, NT does have a slight regression too but nowhere near this much. I assume this is some unfortunate effect of bleeding's bitmap and changed hash tables sizes? Maybe a number of factors just happen to line up with bad luck here?

magnum

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ