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.