[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANJ2NMMUyUeW8vVmUrvzLbkbyb=ka=cfQ7jxWfwUL4JaU7nAqQ@mail.gmail.com>
Date: Tue, 3 Apr 2012 22:34:48 +0800
From: myrice <qqlddg@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: fast hashes on GPU
On Sat, Mar 31, 2012 at 2:46 PM, Solar Designer <solar@...nwall.com> wrote:
>
>
> The first time set_salt() and crypt_all() calls are made for a given
> salt, you process that salt separately (do the actual hashing), but you
> also record the salt value. For your purpose, you'd want to record it
> from your GPU code, so that it can access the salt directly next time.
> You also record a copy of it from your CPU code. The second time the
> set_salt() and crypt_all() calls are made (for previously seen salts
> since no new hashes and thus no new salts may be loaded during
> cracking), you do the bulk hashing (for all previously seen salts) on
> the very first call to crypt_all(). Yes, you must do it as soon as you
> see the same salt value again - including for salts that have not yet
> been seen for a second time. You can't delay processing of the current
> salt because cmp_*() and get_hash*() must return correct values right
> after the crypt_all() call, and you don't want to delay processing of
> further salts because you want the potential speedup from bulk hashing.
>
> Here is questions to this implementation:
1) In real crack, it seems that the second time we saw a previous salt,
we receive all salts in the file(Just as shadow file). Is this right?
2) In benchmark, we only use two salts in fmt_test struct. With many salts,
we repeat use first two (or one) salts for 0x100(256) times. So if we see
the same salt second time, we cannot do bulk hashing.I am still thinking
for it. Any ideas?
On Tue, Apr 3, 2012 at 9:07 PM, Solar Designer <solar@...nwall.com> wrote:
>
>
> You may want to consider offloading the hash comparisons onto the GPU
> first. I expect that this will provide greater speedup than the salts
> thing. The approach to implementing it is similar.
>
> Okay, I will.
> For salts, you'd only achieve an effect very similar to what you'd
> achieve by simply using a much larger max_keys_per_crypt value (more
> work done per one interaction with GPU). Thus, I expect that with or
> without the salts trick, you'd achieve similar performance as long as
> max_keys_per_crypt is properly tuned for each case separately.
>
> Great! It will temporary solve question 2) I mentioned. I will post the
result as soon as possible.
I tested new code on GTX580(THREADS 480, BLOCKS 1024):
Benchmarking: Mac OS X 10.7+ salted SHA-512 CUDA [64/32]... DONE
Many salts: 34065K c/s real, 34065K c/s virtual
Only one salt: 23359K c/s real, 23130K c/s virtual
Thanks!
Dongdong Li
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.
