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.