[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BLU0-SMTP186B6BDEAEB079CDA2A4859FDAD0@phx.gbl>
Date: Tue, 28 Jan 2014 01:10:58 +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/27/2014 01:42 AM, magnum wrote:
> Then again, we/you could implement it in a topic branch and hope it will
> merge without too much effort later.
Attached patch implements much of the logic suggested in my earlier mail.
I bumped the FMT_MAIN_VERSION to 12, and added the new format extension
to all bleeding-jumbo formats, including cuda and opencl, but used
#if FMT_MAIN_VERSION > 11
...
#endif in all format definitions, so that formats should continue to
work for FMT_MAIN_VERSION 12.
listconf.c, loader.c, and john.c don't use #if FMT_VERSION > 11, but I
can easily add this if you prefer.
Alternatively, I can also get rid of #if FMT_MAIN_VERSION > 11 in all
the formats (but there are even some #if FMT_MAIN_VERSION > 9 in there.)
224 files changed, 1228 insertions(+), 6 deletions(-)
sounds like a lot.
But most of the inserted lines come from just the same 5 lines added to
each struct fmt_main (except for thin formats, which are handled in
dynamic_fmt.c.
Currently, bcrypt format (CPU) is the only one which provides correct
iteration counts, so right now it is the only format which profits from
checking whether hashes wich different iteration counts are loaded.
-all other formats, including OpenCL and CUDA formats, currently use
fmt_default_iteration_count, which just returns 1.
So, this patch is only useful for bcrypt right now:
$ ./john --fork=2 bcrypt.hashes --wordlist
Loaded 4 password hashes with 4 different salts (bcrypt [Blowfish 32/32 X2])
Loaded hashes with varying # of rounds (from 16 to 256)
Also, --list=format-methods has been adjusted.
Those salted formats that can have varying iteration rounds will get
their individual iteration_count method in later patches.
Right now, just wanted to have one format fully supporting the new
interface, so that I can test the new functionality, and all the other
formats not breaking (still need to adjust those formats in unstable,
just in case someone is going to need them).
Next steps:
-implement --rounds=COUNT --rounds=-COUNT and , and test it, in
combination with --show[=LEFT] and with cracking modes.
(I wanted to avoid --iteration count, so that -i still works for
--incremental. But may be --rounds will be confusing for users.
Should that question be discussed on john-users?)
-adjust other salted hash formats with configurable iteration count to
use an individual iteration_count method instead of
fmt_default_iteration_count.
-adjust bach completion to mention COUNT and -COUNT as possible
completions for --rounds=
-adjust documentation (--rounds= and --list=format-methods
If you want to test the current patch in your local repo, first use
$ git apply --check
0001-Implement-checks-for-different-iteration-counts-in-l.patch
And then, if the first command doesn't print any errors, use
$ git am 0001-Implement-checks-for-different-iteration-counts-in-l.patch
Or, just look at the top commit of my fd-iteration-count branch:
https://github.com/frank-dittrich/JohnTheRipper/commit/55b64bc9c7a9fb881b37d6db47275064c60d035b
Any suggestions what to change?
Frank
View attachment "0001-Implement-checks-for-different-iteration-counts-in-l.patch" of type "text/x-patch" (111270 bytes)
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.
