|
Message-ID: <20100307211151.GA11664@openwall.com> Date: Mon, 8 Mar 2010 00:11:51 +0300 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: Feedback on the generic crypt(3) patch On Sun, Mar 07, 2010 at 02:25:18AM +0100, Magnum, P.I. wrote: > Sorry again for the spamming, I really thought I got it right but I got > the lengths wrong despite what I thought were valid double-checks. I > enclose a fixed fix of the fix. Like before, this patch can be applied > after Solar's "john-1.7.3.1-generic-crypt-1.diff.gz" This is still not quite it. The encoding strings for SHA-crypt hashes are not always of fixed length. This is only the case when the default iteration count is used (and so it is not specified). Please see: http://people.redhat.com/drepper/SHA-crypt.txt http://www.php.net/manual/en/function.crypt.php Also, when you modify a source file written by someone else, I'd appreciate it if you introduce or edit a comment to state so, as well as what terms apply to your modifications (perhaps place them in the public domain just like I did for the original crypt_fmt.c file). > Another strange thing though. I made up a password file of 1000 entries > using the same salt. SHA-256 performs at ~275000 c/s and SHA-512 at > 119000 c/s. The benchmarks report figures (for "same salt" too) in order > of 1/1000 of that. When I test the same using different salts, it > performs at about the speed as reported by the benchmark. This tells me > there is actually a benefit of duplicate salts Indeed. > which is a surprise in itself, Why is it? The hash computation only needs to be performed once per {candidate password, salt}. When you have many target hashes with the same salt, your effective rate of {candidate password, target hash} increases a lot - and this is what JtR reports while cracking. > and why isn't the benchmark reflecting this? It cannot possibly know how many password hashes with how many salts you'd load for cracking, so it does not try to report the would-be effective combinations rate. Instead, it reports the "raw" rate of "crypts" (password hash computations) per second. You may notice that it nevertheless does report two numbers - for "one salt" and for "many salts", respectively, and these differ from each other a little bit - e.g., by around 10% for traditional DES-based crypt(3) hashes. This difference is primarily due to key setup "overhead". The key setup only needs to be done once per candidate password, whereas the hashing needs to be performed once for every {candidate password, salt} combination. This means that with multiple salts the key setup is performed less frequently than it is with just one salt, and thus the rate of hash computations per second increases. For SHA-crypt, this effect should not be seen (any differences between the two numbers that you might see are either spurious or indicative of an implementation shortcoming). Thanks, 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.