[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CABtNtWFzwQ9MA0dck3UK4TJKQEDm0ocMBJk56Wm3EEgBVDDjNg@mail.gmail.com>
Date: Mon, 24 Aug 2015 15:39:41 +0800
From: Kai Zhao <loverszhao@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: BENCHMARK_LENGTH bugs
Hi Alexander,
On Sat, Aug 22, 2015 at 10:20 AM, Solar Designer <solar@...nwall.com> wrote:
>
> 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.
For the formats that benchmark_length = -1 and salt_size != 0, I
changed the benchmark_length = 0 to run separate benchmarks.
I run a benchmark and collect the formats which maybe have problems.
The formats are in the attached file.
There are some formats whose benchmark_length is -1 but the speed
of "Many salt" is larger than "Only one salt". Such as, KeePass and
chap.
There are 3 formats whose benchmark_length is 0 but the speed of
"Many salt" is smaller than "Only one salt". They are vtp, crypt and
saph.
Thanks,
Kai
View attachment "benchmark_results.txt" of type "text/plain" (4508 bytes)
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.
