Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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.