[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 1 Apr 2012 23:36:24 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: fast hashes on GPU
On Sun, Apr 01, 2012 at 11:42:05PM +0800, myrice wrote:
> 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.
Correct.
> But here is a question,
> will two or more salts be the same in a bunch of hashes?
Yes, it is possible that two or more hashes use the same salt. John has
the necessary logic to detect and take advantage of such matching salts.
> 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?
I fail to see how your observation about possibly matching salts is
relevant here. I think it is not.
...Oh, I think I got it. You're worried that a salt might be seen for a
second time by set_salt() before we've advanced to the next bunch of
passwords? No, this is not possible. John is smart enough not to waste
time on hashing the same passwords with the same salt again, even if
such hashes are present in its input file. Instead, it does the hashing
just once, then compares against the multiple loaded hashes that share
this salt value.
> I think we would load all salts value with first bunch of passwords. So
> what does the missing salts mean?
I think magnum addressed this question already (thanks!)
> > 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.
Please don't forget that you need to implement the keys_changed trick
before proceeding to experiment with the more advanced tricks discussed
here.
> We could also return the location of the matched hash.
You mean, return its number? What if more than one matched? While you
could return some info like that, I am not sure it's worth it - you
could end up slowing down the GPU code whereas the typical case (when
performance is most important) is that there's no match.
Alexander
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.
