Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 3 May 2015 20:09:38 +0300
From: Solar Designer <>
Subject: Re: optimization idea for salted hashes

On Sun, May 03, 2015 at 01:02:42AM +0300, Aleksey Cherepanov wrote:
> It is possible to lift some computations from the loop for some salted
> hashes.
> As the base, I consider a loop over all pairs salt + candidate. So if
> a part of code is computed only for salt not depending on candidate
> then it is possible to precompute it once for each salt. Similarly if
> a part of code is computed only for candidate not depending on salt
> then it may be computed once per candidate (it may be easy to
> implement if we have "for each candidate { for each salt { ... }}"
> structure of the loop).
> Is the optimization implemented in john?

Sure.  Also, both salt setup and key setup may be moved out of the inner
loop at once.  In fact, this was a reason to support and use higher
max_keys_per_crypt even back when early JtR supported only descrypt, and
before it was bitsliced.  With moderately high max_keys_per_crypt, the
algorithm is roughly as follows:

	for each key
	end for
	for each salt
	end for

where crypt_all() may have an internal loop over previously prepared
keys.  When there's just one salt, set_salt() is done just once, but
that's a minor detail (with large max_keys_per_crypt, the salt setup
overhead is low).


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.