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.