[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 9 Jan 2007 23:01:21 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: NTLM patch performance
I wrote:
> >There's a much more efficient implementation of the NTLM hashes support
> >for JtR in Simon Marechal's bigpatch as linked from this page:
> >
> > http://www.banquise.net/misc/patch-john.html
> >
> >It will do 2 or 4 hashes in parallel on MMX or SSE2, respectively.
On Sun, Jan 07, 2007 at 05:24:36PM -0800, Alain Espinosa wrote:
> The performance its similar to SamInside. I wonder why this patch
> isnt in john bigpatch?
Actually, it is in Simon's bigpatch. It is not in the jumbo or "all"
patch as maintained by Erik. Perhaps Erik and Simon could discuss the
integration of this code into the jumbo patch and do it. ;-)
> >Have you tried ElcomSoft's Proactive Password Auditor? It's not cheap,
> >but recent versions are very fast:
>
> I try it and are a bit worse than SamInside and Simon Marechal's bigpatch.
What CPU did you test this on? What performance numbers are you
getting, specifically, and for how many loaded hashes?
> SamInside its 2 times faster when cracking one only hash that when
> cracking any more. Any idea why?
Well, with fast implementations of fast hashes, comparisons of the
computed hashes against loaded ones take a non-negligible percentage of
processing time. So efficient "indirect" comparison algorithms need to
be used in order to maintain good effective c/s rates with multiple
hashes loaded for cracking. I didn't do this kind of benchmarks with
SAMInside myself, but based on what you're saying, SAMInside might not
implement such efficient algorithms.
The raw hash computations per second rate will decrease with higher
numbers of loaded hashes. This is true for JtR as well. However, this
rate should not decrease that rapidly, so that the reported effective
comparisons per second rate will increase almost linearly with higher
numbers of saltless hashes loaded for cracking.
--
Alexander Peslyak <solar at openwall.com>
GPG key ID: 5B341F15 fp: B3FB 63F4 D7A3 BCCC 6F6E FC55 A2FC 027C 5B34 1F15
http://www.openwall.com - bringing security into open computing environments
--
To unsubscribe, e-mail john-users-unsubscribe@...ts.openwall.com and reply
to the automated confirmation request that will be sent to you.
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.
