[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 1 Apr 2012 14:07:57 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: JtR: GPU for slow hashes
On Sun, Apr 01, 2012 at 03:10:30PM +0530, SAYANTAN DATTA wrote:
> Is there any documentation regarding the functioning of JtR format and its
> associated methods as a whole?
Not much. Please take a look at the comments in formats.h, and you may
review dummy.c as a sample.
> Because I am unable to clearly understand how
> each function shall be invoked during a test and during actual cracking.
While this is definitely related to what you're doing, please note that
you're not supposed to be invoking these functions - you merely provide
them to be invoked by the existing JtR code. As long as your functions
meet the expectations (see formats.h), you should be fine.
> Adding to the complexity I have only implemented the PBKDF2 step on GPU and
> the rest of the steps are meant to run on CPU as you suggested.So when the
> crypt_all() method is invoked do you want to benchmark only the PBKDF2 step
> or the MSCash2 as a whole.
The latter. It is already done this way for Lukas' CUDA implementation.
So you may reuse the existing on-CPU portions from there.
> Benching the whole MSCash2 will/should be
> inherently slower since only the PBKDF2 step will be run in parallel.
This slowdown should be very small. Let's assume that your GPU code
is somehow 100 times faster than the CPU code. You perform one
iteration on CPU followed by 10240 iterations on GPU. Of course, on
GPU you also process many hashes in parallel, but the 100x speedup
figure that we're using here already has that rolled into it. The
portion of code that you run on CPU thus corresponds to about 1% of
total running time per crypt_all() call.
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.
