[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130522103119.GC6483@openwall.com>
Date: Wed, 22 May 2013 14:31:19 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: cmp_all on gpu for descrypt-opencl
On Wed, May 22, 2013 at 11:08:43AM +0530, Sayantan Datta wrote:
> On Wed, May 22, 2013 at 12:21 AM, Solar Designer <solar@...nwall.com> wrote:
> > It is possible with the current (new) format: you implement the
> > comparisons in crypt_all() instead of in cmp_all(). This is why I added
> > the "struct db_salt *salt" argument to crypt_all(). That way, you also
> > avoid a second kernel invocation.
> >
> > I posted an example of this, for LM hashes on CPU, to john-dev last summer:
> >
> > http://www.openwall.com/lists/john-dev/2012/07/21/1
> >
> > You need to look at the changes for DES_bs_crypt_LM() - you may search
> > that posting for "This integer division may be slow - need to revise" to
> > find the right place. (BTW, this comment gives the reason why I haven't
> > merged this portion of the changes into the core tree... but I think
> > magnum did merge it into bleeding anyway.)
> I found that post and downloaded the patches( BTW DES_bs_crypt_LM() patch
> is not in bleeding). I applied the patch to current bleeding and some of
> the variables seems to magically appear during compilation e.g retval.
I don't understand what you mean by "the variables seems to magically
appear during compilation". The patch adds some variables. So what?
> for (index = start; index < end; index++) {
> unsigned int hash = salt->index(index);
> if (salt->bitmap[hash / (sizeof(*salt->bitmap) * 8)] &
> (1U << (hash % (sizeof(*salt->bitmap) * 8)))) {
> struct db_password *pw;
> pw = salt->hash[hash >> PASSWORD_HASH_SHR];
> do {
> if (DES_bs_cmp_one(pw->binary, 64, index)) {
> #pragma omp critical
> retval = keys_count;
> goto done;
> }
> } while ((pw = pw->next_hash));
> }
> }
> done:
> ;
> }
> #endif
> }
>
> #if DES_bs_mt
> return retval;
>
> Focusing on the main loop it seems like we should return
> keys_count(updated keys count if generating passwords) on finding a match
> else we should return 0, right ?
This is a possibility, yes. The comment on crypt_all() in formats.h
includes:
* Returns the last output index for which there might be a match (against the
* supplied salt's hashes) plus 1. A return value of zero indicates no match.
So e.g. if you ended up computing hashes for 10,000 candidate passwords
and you got some matches, but you know that the matches are e.g. within
the first 5000 candidate password indices, then you set *count to 10000
(for proper c/s rate computation and reporting), but crypt_all()'s
return value may be 5000 - or it may be 10,000 as well if the overhead
of determining the lower value to return is not worth it (I guess that
often it won't be).
> Also I didn't understand the bitmap stuff above.
It's copy-paste from cracker.c with minor edits. Please take a look at
it there. If you still don't understand it, please ask specific
questions on it.
> I saw loader.h for bitmap but it is still not clear.
Do you mean loader.c (not .h)?
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.
