[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 23 May 2011 17:06:09 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: BSDI poor in OMP4/OMP7 when doing real work
magnum -
On Mon, May 23, 2011 at 02:37:05PM +0200, magnum wrote:
> Using the OMP4 *or* OMP7 patch on 1.7.7, the BSDI format performs very
> poorly in real cracking (test suite) even though --test show a good
> speedup. Actually the reported figure from real cracking is also high
> but the real time is awful. It does find all 1320 passwords.
>
> Plain 1.7.7:
> --test 77004 c/s
> testsuite 2 seconds, reported c/s 78586
>
> 1.7.7 + OMP4
> --test 128098 c/s
> testsuite 1 minute, 11 seconds, reported c/s 123860
I haven't tried this, but my guess is that the problem may be due to the
increase of *_keys_per_crypt. When your wordlist has all the correct
passwords and nothing else, it is quicker not to test multiple candidate
passwords against each hash (even if partially done in parallel), but
rather to take each one candidate password and test it alone - then
remove the cracked hash (and have less work to do from that point on).
This is a rather fundamental problem, and it is not limited to hashes of
this type (but you need slow hashes to notice it).
Perhaps max_keys_per_crypt should be adjusted dynamically based on the
actual number of threads, to avoid having too much parallelism, which
sometimes hurts. BF_fmt.c does that.
This also shows that test runs don't reflect real-world usage very well;
they only reflect a special case well. If you had mostly wrong
passwords in your wordlist, you would in fact see a speedup from OpenMP.
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.
