Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 3 May 2015 20:09:38 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
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
		set_key()
	end for
	for each salt
		set_salt()
		crypt_all()
	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).

Alexander

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ