[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <486d69bb14b23bb8162efdd6df3d9428@smtp.hushmail.com>
Date: Fri, 4 Jan 2013 15:34:04 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Supporting different hash algorithms with a single format?
On 4 Jan, 2013, at 13:08 , Frank Dittrich <frank_dittrich@...mail.com> wrote:
> What do you think? Should separate hash algorithms be supported by
> different formats, instead of mixing different hash algorithms into the
> same format?
Just like you, I think it's best to split when performance differs a lot. However, this might be just confusing for the end-user [traditionally called luser from now on], who just want to launch JtR and be done with it. Let's say luser does something like this:
$ ./odf2john.py path/*.odf >odf.in
$ ./john odf.in
Now, if we have one format supporting both algos John will start cracking both, NQA, but the "harder" document will slow down the crack of the "lighter" one (with no notice) in ways the luser may not grasp (OTOH, same thing happens with normal hashes using different iteration counts).
But if we have two different formats, luser will get those ambigous-format warnings and just one of the formats will auto-load (preferrably the fastest). Then luser will need to start another instance with a --format option given.
Neither option is perfect. A third/new way to handle it (just thinkin' out loud) is to make use of --subformat for this and keep it one format. If you do not pass --subformat, it will load all of them just like current ODF do. If you do, it will technically work fairly similar to --salt for normal hash formats. A side-effect would be that benchmarks would show a useless mix of all test vectors unless --subformat is given to --test.
Would this be a good idea? And would it be straight-forward to implement? I think it would.
> Are you aware of other formats mixing different hash algorithms?
Office CPU format does. I split the OpenCL version into three. Sadly, I did this in three separate source files, which was a Bad Idea[tm] that give me three times more maintenance. I should eventually combine them into one file with three formats.
I think there's more but I can't remember right now.
WPA-PSK has two different post-processing algorithms (MD5 or SHA1) but the speed should be damn near identical because both derives key from 8192 x SHA-1. For such cases it's obviously better to combine them.
Another aspect of all this is that when you load a file with eg. AES-256, the format will currently print "ODF SHA-1 Blowfish / SHA-256 AES" as if that was loaded. This is not Dhiru's fault but a problem with how core John works and/or its conventions. I'm not sure how we could change this in a good way, but it would be nice if that output actually reflected what was loaded (one or several algorithms) while the benchmark comment could output all supported algos... or something like that?
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.
