Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ