[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CANO7a6zPzEuQDy9wjJ4S+5HHvfP4hq0suLcKGz2NCT_hUaBUoQ@mail.gmail.com>
Date: Sat, 14 Apr 2012 21:40:27 +0530
From: Dhiru Kholia <dhiru.kholia@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: PDF format
On Thu, Apr 12, 2012 at 10:16 PM, jfoug <jfoug@....net> wrote:
>>This is now done and committed to magnum-jumbo. However "many salts"
>>case is still slower than "one salt" case. Is this due to initPDFCrack
>>function being called from set_salt?
>
> It appears very likely, this also requires pre-computation, so that it is
> ONLY done one time, at program start. This requires memory.
>
> Thus, you probably want to keep this initPDFCrack, passing in the pointer to
> the salt structure being built. This 'salt' structure would have pointers
> for all data created within the initPDFCrack() or any functions it calls.
> It looks like a lot of allocations, memcpy's, byte twiddling, etc. Again,
> ALL of this work is being done each set_salt, when we could eliminate this
> and do it only once in get_salt (at program load).
>
> However, you still need to 'put' this pre-computed data into the pdfcrack
> static pointers (or int sizes, etc). So there will probably need to be a
> loadPDFCrack() function, which you pass in the salt pointer, and this
> function loads all the static data, but does not have to compute it again
> and again (hopefully everything is just pointers, or ints).
Thanks for the help Jim. I was able to fix multi-salt performance
problems. Can you take a look at the new source?
$ ../run/john -format=pdf -t
Benchmarking: pdf [32/64]... DONE
Many salts: 33599 c/s real, 33599 c/s virtual
Only one salt: 33905 c/s real, 33905 c/s virtual
OMP support is next (but all those global variables will cause problems).
--
Cheers,
Dhiru
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.
