[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20130603151526.GB27593@openwall.com>
Date: Mon, 3 Jun 2013 19:15:26 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: cmp_all on gpu for descrypt-opencl
On Mon, Jun 03, 2013 at 08:29:59PM +0530, Sayantan Datta wrote:
> On Mon, Jun 3, 2013 at 7:46 PM, Solar Designer <solar@...nwall.com> wrote:
> > 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 ?
We'll need to implement set_mask() and mask mode as proposed last year.
> > 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
Oh, indeed. I forgot about the kernel building time, which for 2243
salts (and kernels) is definitely greater than 2 minutes.
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.
