[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BLU0-SMTP1846B2F15521C171482FE45FD140@phx.gbl>
Date: Thu, 24 Jan 2013 10:37:44 +0100
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Supporting different hash algorithms with a single
format?
On 01/04/2013 03:34 PM, magnum wrote:
> 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.
Any decision what to do with ODF / MS Office formats before releasing
jumbo-8?
I was just using relbench on a jumbo-7 and a jumbo-8-unstable test (CPU
only so far), and remembered we had this discussion, but apparently no
conclusion.
Also, what about PDF?
Jumbo-7:
Benchmarking: PDF MD5 RC4 [32/64]... DONE
Many salts: 16855 c/s real, 16688 c/s virtual
Only one salt: 16881 c/s real, 16881 c/s virtual
Jumbo-8:
Benchmarking: PDF MD5 SHA-2 RC4 / AES [32/64]... (4xOMP) DONE
Many salts: 66304 c/s real, 16617 c/s virtual
Only one salt: 64768 c/s real, 16355 c/s virtual
Apparently, the jumbo-8 version gained OMP support, plus support for
additional algorighms.
But if I compare the virtual c/s rates, it looks like the top two test
cases refer to the algorithm which has been supported in jumbo-7.
Is the performance of the different PDF algorithms more or less the
same, so that it would be OK to map "PDF MD5 RC4" to "PDF MD5 SHA-2 RC4
/ AES" in benchmark-unify?
Or should these be separate formats?
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.
