[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
