[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1315a717ec91ff4d96c3f22e2e6805f8@smtp.hushmail.com>
Date: Tue, 07 Apr 2015 22:55:57 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: [GSoC] John the Ripper support for PHC finalists
On 2015-04-07 19:51, ba wrote:
> On 06.04.2015 18:37, Frank Dittrich wrote:
>> Instead of adding two new command line options, you would be able to
>> access options.loader.min_cost[i] and options.loader.max_cost[i], once
>> you implement tunable cost reporting for pomelo, as I suggested earlier:
>> http://openwall.com/lists/john-dev/2015/04/01/11
>
> I have access when I make extern struct options_main options;
You should just include options.h to get the declaration for options.
> I remember about this that the kernel is cached but after
> the compilation is auto tuning and I don't know If it's better to make
> only once auto tuning for various parameters or auto tuning many
> times for different parameters
This is a design choice with pros and cons. For a real crack run, you
can either compile and auto-tune for each different cost (tedious, slow
start, but optimal run) or just pick settings that can manage all loaded
costs and auto-tune with eg. the hardest case (easier, quicker start,
less optimal run).
There are possibilities not mentioned yet btw. For example, you could
compile a kernel for each cost and keep all of them in memory at once,
calling the appropriate one for each salt. Instead of just calling "the"
kernel, you would call eg. kernel[n]. The unused kernels will not take
much resources. Our DEScrypt kernel can optionally hold thousands of
kernels at once, each hard-coded for a specific salt. Slow start, but
much faster run.
>> You could access the --cost values specified on the command line, but
>> there's no reason to do, see magnum's recommendation to tune for the
>> hashes that actually got loaded:
>> http://openwall.com/lists/john-dev/2015/04/03/12
>
> at the first time when reset is called db=NULL so I don't know which
> hashes are loaded, sometimes (with or without the --test I don't
> remember) reset() is called before init().
When db==NULL you know that you will crack test vectors. You do not
(yet) need to know which hashes are loaded.
I do not think reset() is ever called before init(). Nearly all OpenCL
formats would crash if that happened. Hmm or maybe it could happen when
db != NULL? But that should not be a problem anyway. Just code reset()
to be independent from init().
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.
