[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+TsHUADLMN_--cUSFib7+XT4vMmTw7udxur3zfpPvU-U7nVRg@mail.gmail.com>
Date: Mon, 3 Jun 2013 20:29:59 +0530
From: Sayantan Datta <std2048@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: cmp_all on gpu for descrypt-opencl
On Mon, Jun 3, 2013 at 7:46 PM, Solar Designer <solar@...nwall.com> wrote:
> Hi Sayantan,
>
> On Mon, Jun 03, 2013 at 07:12:45PM +0530, Sayantan Datta wrote:
> > I have implemented a password generator which can crack all numeric(upto
> 8
> > digit) password for descrypt. I have also tested it using a few hashes
> from
> > the test-suite. The generator is integrated with finalize_keys and
> doesn't
> > use global memory. It is also very light on registers. The password are
> > saved to global memory only when positive. The comparisons are done in
> gpu.
> >
> > The code is currently in my git hub repo , bleeding-jumbo branch.
> > https://github.com/Sayantan2048/JohnTheRipper.git
>
> I just took a look. Overall, this is a nice experiment, but there are
> two major issues with the approach taken:
>
> 1. The passwords generated by JtR are totally ignored by this
> descrypt-opencl hack, which generates its own all-numeric candidate
> passwords instead. What we need is to have the GPU substitute all
> possible characters (out of the currently configured charset) into a few
> character positions, but leave the rest as generated by the host.
>
How to get the charset configuration ? How is the position to be
substituted determined ?
> 2. You use modulo division, which probably has high cost of its own.
>
I'll look for some alternative for modulo division but this is temporary.
>
> What speeds are you getting? After 5 minutes of running on one descrypt
> hash (for other than an all-numeric password, or it would get cracked
> within seconds) on bull's 7970, I get a reported speed of 83M c/s (not
> sure if the calculation is correct or not, though, as it obviously
> depends on correctness of your *pcount updates). This is somewhere
> inbetween of what we had before and what we should be able to achieve.
>
Yes I get similar result on my 7970 too. I think better results are
possible if we can keep the GPU occupied for longer time.
Maybe compute more hashes every crypt all call(not by increasing GWS).
>
> Running on "3269 password hashes with 2243 different salts", I get
> reported speeds of as low as "500752c/s 684361C/s" after 2 minutes (and
> not a single password is cracked yet, even though several are
> all-numeric). Where's the new bottleneck? With password generation on
> host, your descrypt-opencl was ~50 times faster at this sort of test.
>
> This is most likely due to the fact 2243 kernels are being build at
runtime. You may try changing the parameters in DES_bs_WGS.h
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.
