[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 1 Apr 2012 23:42:05 +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:
>
>
> You can do it without changing the formats interface and benchmark code.
> Here's how:
>
> 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.
>
> I think you mean that with each new salt is set( that is during first
bunch of passwords), we record it. Then the second, third and so on bunch
of passwords, we can use the salts we recorded. But here is a question,
will two or more salts be the same in a bunch of hashes? If so, we should
process bulk hashing(many salts with a bunch of passwords) right after the
all salts are recorded and second bunch of passwords are set. Not the
second time we see the same salt, right?
When a salt is finally seen for a third time and thus it's time for you
> to invoke the GPU code again, you may also use this opportunity to
> notify your GPU code of the now-missing salts (so it will learn of that
> with a delay of one full set of candidate passwords, but that's OK).
>
> I think we would load all salts value with first bunch of passwords. So
what does the missing salts mean?
> A similar trick may work for recording of hashes to compare against in
> cmp_all() and then moving the comparisons onto the GPU starting with the
> second set of candidates. Then you only need to transfer one bit
> (literally) per GPU code invocation back to the CPU most of the time
> (that bit will mean "no matches" or "there might be matches, please
> request detail"). Once this is implemented, we might even want to
> adjust the thresholds for use of hash tables such that those are not
> used (as that would result in get_hash*() calls being made instead of
> cmp_all(), thereby not letting you offload the comparisons onto the
> GPU). That's a separate task, though.
>
> Ok, this is what I just want to do next. We could also return the location
of the matched hash.
> It'd be very nice if one or more of the GSoC candidates attempt this and
> demonstrate some results now.
>
> Yes, I will do it. However, I am afraid I will have time on Tuesday. I
will inform you as soon as I have some updates.
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.
