[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BLU0-SMTP28843FD28C068C331EE709EFDAF0@phx.gbl>
Date: Thu, 30 Jan 2014 02:09:15 +0100
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Handling of hashes with different iteration counts
On 01/28/2014 09:49 AM, Frank Dittrich wrote:
> Alexander,
>
> thank you very much for your valuable input.
> I'll incorporate many of your suggestions into V2 of this patch.
I have a revised version ready, see
https://github.com/frank-dittrich/JohnTheRipper/tree/fd-iteration-count
https://github.com/frank-dittrich/JohnTheRipper/commits/fd-iteration-count
(I kept the branch name, even though it is now somewhat misleading.)
The top commit
https://github.com/frank-dittrich/JohnTheRipper/commit/98cebc5a2f793bf9894029527b6e429a10ef940c
has the title
"Checks for different values of tunable costs in loaded hashes"
In the commit message and the source code (format interface, loader,
listconf.c, john.c) I replaced every reference to iteration counts to
more appropriate names.
In addition to format methods cost[FMT_TUNABLE_COSTS] there is now a new
parameter tunables[FMT_TUNABLE_COSTS], an array of descriptions for
tunables reported by the particular format.
If these descriptions are not NULL, I use them (instead of the counter
of the tunable costs) when reporting different min. and max. value of a
tunable cost.
I also list the descriptions of tunable costs as a comma separated list
in the --list=method-details and --list=method-all-details output.
Still bcrypt is currently the only format using it.
But all other formats will work as before, because I adjusted all of
them (including OpenCL and CUDA, just not those in unused).
The only test for OPenCL and CUDA formats was a successful compilation
of linux-x86-64-gpu on bull.
Since all the errors I made in CPU formats already surfaced during
compilation (--test and even cracking sessions for all the formats
didn't cause any errors after I fixed all the compilation warnings),
I don't expect any trouble.
The new options --cost=VALUE and --cost2=VALUE will be a problem,
because we run out of flags, unless I am missing something obvious.
Any suggestion how to proceed here?
I could also start implementing useful cost methods for those formats
with tunable costs. This would at least print warnings when the loaded
hashes have different costs.
But if the patches will only be accepted after --cost= has been
implemented, I'll probably wait until there's a solution for the flags.
Frank
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.
