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.