[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+TsHUBtrtLQuQo9c1QyvECw6apV0V3274GqoHTctTYOcQ75Qw@mail.gmail.com>
Date: Wed, 1 May 2013 03:55:24 +0530
From: Sayantan Datta <std2048@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Re:password generation on GPU
Hi Myrice,Solar,
On Tue, Apr 30, 2013 at 4:42 AM, Myrice Li <qqlddg@...il.com> wrote:
> md5_kernel generate
> password by appending [a-z0-9][a-z0-9] for a given password. It also
> mixes with bitmap and the code need to be cleaned also...
>
I can see that the new md5_kernel is using a different format interface
necessary for password generation on GPU. Is this interface final(or close
to being final ) ?
Also I'm trying to understand the new interfaces used with the md5_kernel
in PG-test branch. This is what I think is happening, please verify :
1. Before/during self test:
The 'loaded_hash' value is zero and crypt_all returns *pcount number
of hashes. The first *pcount computed hashes corresponds to first *pcount
plain_texts. All the comparisons are done in cpu.
I guess up to this point everything is similar to what we have been doing
previously.
2. reset is called after self test. Inside reset we load the hashes to be
cracked into GPU memory.
3. After reset:
We have non-zero value for loaded_hash . *pcount number of
candidates are passed to GPU where it locally generates gws x 53 x 53
candidates. So we update *pcount *= 53*53 for calculating c/s. The
comparisons are done in GPU itself and only the matched results(keys and
corresponding hash) are returned from the gpu. crypt_all returns the value
of loaded_hash . Hence only loaded_hash number of comparisons are made in
CPU. get_key() is modified accordingly.
Regards,
Sayantan
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.
