Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 26 Mar 2011 11:02:06 +0300
From: Solar Designer <>
Subject: Re: NTLM scalability improve

On Fri, Mar 25, 2011 at 01:11:10AM +0100, magnum wrote:
> On 2011-03-24 22:42, Alain Espinosa wrote:
> >Changes to NTLM format to perform better with huge number of hashes.
> >
> >As you can see the improve is significant.

Thank you, Alain!

> You can say that again! I tried it with 2M test hashes. Without this 
> patch, just _loading_ them took 47 seconds, then the c/s was reported as 
> 31200M (even though the initial loading time does not affect the c/s 
> figure).
> With the patch, loading them took about 2 seconds, after which it 
> completed inc:digits in about 39 seconds (still 6 seconds before the 
> unpatched version even had started cracking!). And speed was reported as 
> 5698005M c/s...

Sure.  We should have recalled that these hash functions were still
missing in the NTLM code a lot sooner.

BTW, I am thinking of adding two more hash table sizes (for use by all
"formats") - 16M and 256M entries.  This will be handy if someone loads
the RockYou 32M passwords with 1.7.7's "dummy" format, such as for
testing of a ruleset.

> ...speaking of that, I enclose a patch that make John say 5698G c/s 
> instead (it's from fullMPI), is there any reason not to include this in 
> the Jumbo?

Yes: I've just included this "feature" in the main tree. ;-)

	if (cps.hi > 232 || (cps.hi == 232 && cps.lo >= 3567587328U))
		sprintf(buffer, "%uG", div64by32lo(&cps, 1000000000));

(I've made the check more precise.)



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.