|
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.