[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120325091749.1WHHU.134858.imail@eastrmwml108>
Date: Sun, 25 Mar 2012 9:17:49 -0400
From: <jfoug@....net>
To: john-dev@...ts.openwall.com
Cc: Solar Designer <solar@...nwall.com>
Subject: Re: PDF format
Dhiru,
The logic in get_salt() and set_salt() should be reversed.
In pkzip format, (which could be used as a reference on 'how' to do this), in the get_salt() I create a complex structure, taking a lot of time, and doing a lot of validation/loading, etc. I then simply return the address to this structure, using an allocated pointer (which points to the just created structure). Then within set_salt, the code is VERY simple, and quick. Here it is on whole.
static void set_salt(void *_salt) {
salt = *((PKZ_SALT**)_salt);
}
It simply sets a pointer variable. This also means that salt_size within pkzip format is simply the size of a pointer.
Within pdf (and a few other formats), a lot of time is spent within the set_salt function, parsing, allocating, setting up a complex structure. This type of work should NOT be done within the runtime loop. If done in set_key(), then it is in the runtime loop, and each salt computation will be done for EACH salt for EACH password (block of pw's) attempted. This time spent in set_salt() will GREATLY slow down the format.
If this same logic is moved to get_salt(), then it will be done ONE time, for each salt, at the load time of john. There will be no runtime penalty for a 'complex' salt.
Jim.
---- Solar Designer <solar@...nwall.com> wrote:
> Dhiru -
>
> Benchmarking: pdf [32/64]... DONE
> Many salts: 18305 c/s real, 18305 c/s virtual
> Only one salt: 37663 c/s real, 37881 c/s virtual
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.
