Date: Fri, 21 Aug 2015 05:31:27 +0300 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Subject: Re: BENCHMARK_LENGTH bugs Kai, On Fri, Aug 21, 2015 at 09:45:21AM +0800, Kai Zhao wrote: > The speed of dominosec8 is 3471 c/s, and the speed of 7z is 3056 c/s. > The 3471 c/s and 3056 c/s is not very slow ? There are about 16 > formats whose speed is small than 3056 c/s ? What speed can be > recognized as "slow" ? This is irrelevant, because: > If I understand "slow" correctly, then the difference between > "Only one salt" and "Many salts" has nothing to do with "slow" ? There's correlation, but not more than that. I only mentioned "slow" as the typical case where we'd often avoid running two benchmarks, but clearly there are exceptions like these two, where we'd want to run separate "Only one salt" and "Many salts" benchmarks anyway. Extra detail, which is probably overkill for you: In terms of code, what matters is whether there's significant processing done per candidate password yet shared for all salts. We do this in set_key(). If all max_keys_per_crypt calls to set_key() combined are e.g. 1000 times quicker than crypt_all(), then we likely don't want to run separate "Only one salt" and "Many salts" benchmarks. (And indeed we also won't if the hash is unsalted, regardless of how fast or slow its set_key() is.) However, there are exceptions to this: sometimes would-be-set_key()'s expensive processing is postponed until crypt_all() (e.g., in order to put it inside an OpenMP parallel region), yet is effectively only done per key (and is skipped on further crypt_all() calls). 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.