Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 16 Aug 2012 12:32:57 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Result of hard core password generation on 7970

myrice -

On Wed, Aug 15, 2012 at 12:23:38AM +0800, myrice wrote:
> Sorry for late replay. It is on the github now. I implement 4 bitmaps
> but on global memory, it is still 16MB for each bitmaps. I will
> enlarge it later. Currently I use 4*8KB = 32KB local memory for
> bitmaps. I find performance decrease in 4 bitmaps case. It may due to
> more work(compute for bitmaps) in kernel. But for hashes in local
> memory case, it really need optimization. Here is the result:
> 
> 1:
> guesses: 0  time: 0:00:01:36 0.00%  c/s: 1752M
> 
> 1000:
> guesses: 0  time: 0:00:01:40 0.00%  c/s: 1682G
> 
> 1M:
> guesses: 0  time: 0:00:02:01 0.00%  c/s: 648120G

While testing this against the previous revision, I noticed that it
tries a different set of passwords.  Previously, your code was appending
not only two-character combinations, but also individual characters.
So, for example, running it with -i=all8 would crack not only 10-char
passwords, but also 9-char ones.  Now you've corrected this.

With either version, your crypt_all() is returning inflated computed
hash counts.  It uses:

        *pcount *= 53*53;

whereas with old code you only tested maybe (1 + 52 + 52*52) _different_
candidate passwords, and with new code you're now testing 52*52 of them
(I think).

If you're actually computing 53*53 hashes even though the number of
different tested passwords is less, then that's a bug in the OpenCL code
as well.

As to the slowdown with this change, you have lots of other non-optimal
things in the code, and they have changed somewhat along with the change
to bitmaps.  I guess you'll have to start optimizing the code (and the
algorithm, including moving some of MD5 steps out of the loop and
reversing some steps from the end) before we're able to fine-tune the
choice and sizes of bitmaps to use.

BTW, it's time for your weekly report.

Thanks,

Alexander

Powered by blists - more mailing lists

Your e-mail address:

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