[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAF5WNqk3iG_z_dUtiioWYUWFP4crY-8roLAbuyUFCyAUTxnRpw@mail.gmail.com>
Date: Mon, 12 Apr 2021 11:48:43 -0700
From: David Sontheimer <david.sontheimer@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: Cracking stats: p/s, c/s and C/s. Hashing cost factors.
Alexander,
Many thanks - this is all very helpful. Some follow-up questions below.
> Here's an excerpt from doc/FAQ:
>
> speed metrics are as follows: g/s is successful guesses per second (so
> it'll stay at 0 until at least one password is cracked), p/s is
> candidate passwords tested per second, c/s is "crypts" (password hash or
> cipher computations) per second, and C/s is combinations of candidate
> password and target hash per second.
Perhaps I'm approaching it with non-specific terminology. After
reading the FAQ and your explanations, let me try again.
Hash: A cryptographic hash of a cleartext password (and potentially a
salt) stored in a password file. Aka a password hash. The thing we're
using JtR to crack. Therefore g/s is the number of target hashes
successfully cracked per second.
Crypt: A cryptographic hash generated by JtR from a candidate password
(and, if present in the password file, salt). If a crypt matches a
hash, JtR records the associated candidate as a successful guess to
the pot file.
Combination: Candidate password I understand, but which "target hash"
are we referring to - a password hash, correct? If so, then C/s is the
speed with which JtR compares a candidate's hash to a target hash? And
if subsets of target hashes share a salt, JtR will compare a
candidate's hash to the entire subset of target hashes until it finds
a match - allowing for C/s >= c/s.
Therefore, I should not refer to c/s as crypts tested, but crypts
generated, correct?
> When there are
> matching salts (fewer different salts than hashes), some hash
> computation results are reused for multiple comparisons against loaded
> hashes (combinations of computed and loaded hashes).
I'll run some new experiments to see if I better understand how
candidate passwords, crypts and Combinations relate in time-to-crack.
> Unrelated, you probably actually want to consider sha512crypt, not
> sha256crypt. sha512crypt is commonly used, sha256crypt is unusual.
>
> Or consider both so that you can show sha512crypt providing a much
> better (lower) ratio between its cracking and authentication speeds.
Unrelated, sure. Helpful - most certainly. Much appreciated.
> I assume you mean sha256crypt. Yes, that's its default and what we
> benchmark it with.
> Again, you should refer to hashes by their proper names. Clearly you
> don't literally mean SHA-256 and SHA-1 here (these are unsalted hashes
> and don't use any iterations). You probably mean sha256crypt and
> sha1crypt.
Yes, sha1crypt and sha256crypt. Thank you for catching both.
> Meanwhile, you can lock the benchmark
> to one of these two iteration counts using...
Great - this is exactly what I need.
Thank you again,
-David
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.
