[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
