[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150503170937.GB13162@openwall.com>
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
