Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 25 Jul 2012 16:30:16 +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, Jul 25, 2012 at 06:12:00PM +0800, myrice wrote:
> Here is the new rough result
> 
> 1: with 2048*8, ~900M c/s, but with 2048*16, it is ~500M c/s

OK, this is starting to become reasonable.  Have you also tried values
smaller than 2048*8?

> 1000: with 2048*8, ~45G = ~45M, with 2048*16, ~90G = ~ 45M

I understand what you mean by "~45G = ~45M", but why "~90G = ~ 45M"?
I think you're confused.  At 1000 same-salt hashes, "90G" reported
effective speed (combinations per second) means 90M hashes computed per
second.  max_keys_per_crypt is not part of that equation.

(I definitely need to improve speed reporting to avoid such confusion.)

> 1M: still cannot get, I reduce the global work size to 128 and only
> append[a-e][a-e], it is very slow. And the kernel cannot finished with
> [a-z][a-z].
> 
> I am think about compare, with 1M hashes, the loop inside one thread
> increased to 26*26*1M = 676M, it is very large for a thread.

As discussed, you absolutely must implement bitmaps and hash tables on
GPU.  Your direct comparisons are only good for very small numbers of
loaded hashes and for early experiments with larger numbers, like what
you're doing now.  As you've reached this milestone, you should now
proceed further - to bitmaps and hash tables.

Thanks,

Alexander

Powered by blists - more mailing lists

Your e-mail address:

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