Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 31 Mar 2012 04:22:34 +0800
From: myrice <>
Subject: Re: fast hashes on GPU

On Thu, Mar 29, 2012 at 9:01 PM, Solar Designer <> wrote:
> Please see above as it relates to not resending the same candidate
> passwords.  As to the salts, with the current interfaces they have to be
> sent one by one by crypt_all(), and that's sort of fine - these data
> transfers are tiny and you interact with the GPU at that time anyway
> (you ask it to go ahead and process the previously provided bunch of
> candidate passwords with the next salt).  There's room for improvement
> here, but it's primarily about not interacting with the GPU at these
> times at all (so it's not a trivial improvement to make), not about
> avoiding those tiny data transfers.
> Alexander

Yes, I mean what you said. We can compute all combination of salts and a
bunch of password with invoke one kernel. So for benchmark, we have to add
a bench_set_salts for that? I don't know if it good to change the interface
at this time. However, I will test for the performance.

Besides, I write xsha512-cuda format. Optimization is needed. I put it to
my github:
However, it is really very slow now. In my P8600 and G9600M GS, it's 1.5M
and 1M. I will stay tuned.
Here are benchmarks:
Benchmarking: Mac OS X 10.7+ salted SHA-512 [64/64]... DONE
Many salts: 1553K c/s real, 1564K c/s virtual
Only one salt: 1487K c/s real, 1497K c/s virtual

Benchmarking: Mac OS X 10.7+ salted SHA-512 [64/64]... DONE //Forgot to
Many salts: 983040 c/s real, 1007K c/s virtual
Only one salt: 955733 c/s real, 955733 c/s virtual

Content of type "text/html" skipped

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.