Date: Wed, 6 May 2015 21:11:23 +0300 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Subject: Re: optimization idea for salted hashes On Wed, May 06, 2015 at 08:49:38PM +0300, Aleksey Cherepanov wrote: > Some thoughts on design of formats: > > At first, it looked natural to put the code that depends only on > password into set_key() but then I realized that set_key() may mangle > only 1 candidate while it would be more efficient to collect a pack > and process it. So the processing should be in crypt_all() that may > work with packs. So for salted hashes, a format have to store a flag > to indicate that a candidate is already processed. Yes. Having the processing directly in set_key() is a bit outdated. It worked well in simple cases, but not so well e.g. with the new bitslice DES key setup in 1.7.9+ and with OpenMP. Continuing this example, what the bitslice DES code does now is have set_key() only transpose the chars matrix, because it's roughly same cost per key as a strcpy()-alike would be anyway, and is trivially undone in get_key(), and have crypt_all() take care of the bit-level processing. > Though the flag may be needed for non-salted hashes too for other > reason: we can't mangle candidates in-place without it: get_key() may > be called right after set_key() (at least during self test) and after > crypt_all() so get_key() have to decode the candidate back after and > only after crypt_all() and not right after set_key() when the > candidate is not mangled yet. Yes, although I don't recall us having this in any format currently. There are saltless formats where set_key() doesn't fully setup the key, but crypt_all() finishes that (to have more of the processing within an OpenMP parallel section or/and benefiting from SIMD or/and interleaving). A notable example is LM. It works like I described above, but unlike descrypt it lacks the flag you mentioned, because crypt_all() is only called once. The problem you mentioned does not arise there because the key setup isn't finished in place: we read from xkeys and write to K. get_key() would read from xkeys regardless of whether it's called before or after crypt_all(), and it will produce the same result. > So raw-sha512 with sse does padding and alters endianity in set_key() > storing only the result in global buffer, in get_key() it does the > reverse to return candidate to john. Moving padding to crypt_all() > that modifies the global buffer needs the flag to make the reverse > actions optional. I haven't looked into that format's specifics, but what you describe sounds like one valid way to handle the problem. 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.