Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 24 Aug 2015 15:39:41 +0800
From: Kai Zhao <>
Subject: Re: BENCHMARK_LENGTH bugs

Hi Alexander,

On Sat, Aug 22, 2015 at 10:20 AM, Solar Designer <> 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

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



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.