[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150822022057.GB8588@openwall.com>
Date: Sat, 22 Aug 2015 05:20:57 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: BENCHMARK_LENGTH bugs
On Fri, Aug 21, 2015 at 01:22:40PM +0800, Kai Zhao wrote:
> On Fri, Aug 21, 2015 at 11:17 AM, Solar Designer <solar@...nwall.com> wrote:
> > On Fri, Aug 21, 2015 at 11:03:19AM +0800, Kai Zhao wrote:
> >> Could we define slow: whose speed is less than e.g. 1000K c/s ?
> >
> > As per the previous few messages, we shouldn't define slow for the
> > purpose of your current work. Since this was merely correlation and we
> > already know counter-examples, we shouldn't focus on this aspect.
> > We should instead focus on whether the "Many salts" and "Only one salt"
> > benchmarks results are expected to be different or almost the same.
>
> The benchmark_length should be 0 if the speedup from "Only one salt"
> to "Many salts" is greater than 1%.
Yes.
> Otherwise, it should be -1. Is this right?
Not exactly. e.g. 0.5% is still significant enough that I'd like to see
it _if_ there are good reasons for this difference to exist. So the
ultimate decision is based on our knowledge of what goes on under the
hood (the "overkill" detail I provided to you) rather than on the
difference between benchmarks on a given run.
In other words, if the difference is reliably greater than 1% then we
should run the two separate benchmarks and report their separate results.
If not, then our decision may vary on a case by case basis. If the
difference is extremely small - like all reported digits are literally
the same - then we're very likely to want to mute the separate
benchmarks.
All of the above is for salted hashes only. For saltless, we obviously
must never run these separate benchmarks.
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.
