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.