[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20171201023251.GA8293@openwall.com>
Date: Fri, 1 Dec 2017 03:32:52 +0100
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: benchmarking salt-only formats
Hi,
Some JtR formats are for "non-hashes", where we try to decrypt or
encrypt something (which we make part of a "salt", as far as JtR is
concerned) and compare against another something (also part of a
"salt", and there's never a "hash").
In those formats, binary_size is zero, but salt_size is non-zero.
We call them salt-only formats.
We also have per-format benchmark_length, through which we control a
split of plaintext password lengths for benchmarking (hence the name),
to see separate reporting for Short vs. Long passwords. A value of 0
lets us see separate reporting for Only one vs. Many salts, and a value
of -1 reports just one Raw speed. That's as it is in JtR core tree;
jumbo added some more magic values.
Now, do we want separate reporting for Only one vs. Many salts, or only
one Raw speed for the salt-only formats? I guess the separate reporting
could be useful, except where the format is such that there's almost no
difference between the two speeds (e.g., this is why we report only one
speed for bcrypt; we could extend the same logic to salt-only formats).
Right now, we have this inconsistently - e.g., the recently added
tacacs_plus_fmt_plug.c has separate reporting, but the older
dpapimk_fmt_plug.c reports only one speed. We'll probably need to open
a GitHub issue to remember to unify this one way or the other.
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.
