[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20100308025314.GA13393@openwall.com>
Date: Mon, 8 Mar 2010 05:53:14 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Feedback on the generic crypt(3) patch
In a previous posting, I wrote the following regarding "many salts" vs.
"only one salt" benchmark results:
> >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).
On Mon, Mar 08, 2010 at 03:31:48AM +0100, Magnum, P.I. wrote:
> Why shouldn't it be seen for SHA-crypt? Because key setup overhead will
> be insignificant compared to hashing?
Right. In fact, there's no separate key setup step with those hashes.
A few operations could be taken out "artificially" and performed once
per candidate password only, but this is not done in the implementation
found in glibc anyway.
> FreeBSD MD5, among others, only reports a "Raw" figure, why is that?
It's for the same reason. The code in JtR does "artificially" separate
a few operations for those hashes into a "key setup" step, but the
speedup this provides is negligible (it is hardly even measurable).
You may want to set BENCHMARK_LENGTH to -1 when benchmarking this kind
of hashes.
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.
