[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 08 Mar 2010 03:31:48 +0100
From: "Magnum, P.I." <rawsmooth@...dband.net>
To: john-users@...ts.openwall.com
Subject: Re: Feedback on the generic crypt(3) patch
>> 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
Thanks. The last patch I posted will put out correct benchmark figures
anyway so I'll spare you any more versions until I have completed my
homework.
> 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).
I didn't add any real code so I thought it was obvious. For the record,
my little contributions are hereby placed in the public domain.
>> 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.
But of course. I was confusing the above with the below, but it's really
two different matters...
> 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.
This makes sense but again I tend to confuse it with what you explained
in the previous quote. I guess I need to stop and think.
> 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).
Why shouldn't it be seen for SHA-crypt? Because key setup overhead will
be insignificant compared to hashing?
FreeBSD MD5, among others, only reports a "Raw" figure, why is that? I
can understand why saltless hashes do that.
thanks
magnum
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.
