[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <97ebb7b35593a3d64f47a8193cf53c4c@smtp.hushmail.com>
Date: Wed, 07 Mar 2012 11:07:56 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: OpenCL KPC and LWS
On 03/07/2012 10:03 AM, Samuele Giovanni Tonon wrote:
> On 03/07/12 00:31, magnum wrote:
>>
>> BTW both the LWS and KPC functions should ideally move to opencl-common.
>
> yes i agree, unfortunately there's the "hashing" and prepare part in
> those function which vary from format to format, shall we use a
> commong function in opencl-common and put a pointer function as arg ?
I haven't looked into the details, I can see it's not totally trivial.
You'd need to prepare the specifics in the format, and just move the
common stuff and enumeration loop to common. Hm, or maybe use
callbacks... you mean pointers to set_salt() et al?
Anyway since this code is in a state of flux it would be really nice
with most of it in one place. And some formats might benefit from
getting KPC enumeration added.
>> In the end we could end entries in john.conf:
>> [OpenCL options]
>> platform = 1
>> device = 0
>> ssha_LWS = 512
>> ssha_KPC = 8192
>> phpass_LWS = ...
>>
>
> yes that's exactly what i had in mind but without the entry in john.conf
> (i'm still trying to not modify non opencl code).
Why? A non-OpenCL build will just ignore the entries in the conf without
complaining. From memory I think you won't have to touch any other code.
> (i'm still trying to not modify non opencl code). in that way you can
> call john like this:
>
> export LWS=64
> export KPC=1024768
> ./john -i:all -fo:ssha-opencl /tmp/myhashes
>
> export LWS=128
> export KPC=2097152
> ./john -i:all -fo:mysql-sha1-opencl /tmp/pw-mysql
FWIW I avoid the export (as it will bite me later when I forget it's
there) and just call like this:
LWS=64 KPC=1024768 ./john -i:all -fo:ssha-opencl /tmp/myhashes
LWS=128 KPC=2097152 ./john -i:all -fo:mysql-sha1-opencl /tmp/pw-mysql
But this is tedious to write any way we do it.
> of course if we can add that to john.conf that would be wonderful
> the only problem is, how to trigger the benchmark so then you can
> write down best numbers and never do that again ? we could behave like now:
> - lws il always tested until it's put in john.conf
> - kpc is at max_kpc until you put as 0 in john.conf, get the best value
> for your card and fix the value in john.conf
Keep looking at env variables, if they are there they override the conf.
I've done conf stuff before. I can produce an experimental patch to
demonstrate it for one format.
magnum
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.
