Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 16 Jul 2012 13:40:30 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: xsha512-cuda & xsha512-opencl testing

myrice -

On Mon, Jul 16, 2012 at 04:55:45PM +0800, myrice wrote:
> This time I set password length > 9 and here are some results to fix the above:

"> 8" (9 or above) would have been enough.  Not that this matters.

> Incremental xsha512-opencl 7970 password length > 8
> 1_1
> guesses: 0  time: 0:00:03:24 0.00%  c/s: 14441K

Just a bit faster than current CPU code.  Limited by transfers of
candidates from CPU to GPU, as expected.

> 100_100
> guesses: 0  time: 0:00:04:07 0.00%  c/s: 48790K

OK.

> 10K_1
> guesses: 0  time: 0:00:04:00 0.00%  c/s: 122552M

12M passwords/second, probably limited by transfers of hashes from GPU
to CPU, right?

> 1M_1
> guesses: 0  time: 0:00:03:58 0.00%  c/s: 2788G

2.7M passwords/second, probably limited by large hash table lookups on
the host.  Is this magnum-jumbo (without bitmaps) or bleeding (with
bitmaps)?  I'd expect better speed with bitmaps.  Either way, you need
to implement an equivalent of them on the GPU side.  Not necessarily for
this hash type (where having so many hashes/salt is not typical), but
for saltless hashes mostly (where having millions of hashes and no salts
is common).

Thanks,

Alexander

Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.