Date: Wed, 14 Apr 2021 19:50:30 +0200 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: Cracking stats: p/s, c/s and C/s. Hashing cost factors. On Mon, Apr 12, 2021 at 02:41:48PM -0700, David Sontheimer wrote: > Found and resolved a bug in my code. My stats make a lot more sense now, in > relation to your explanations. > > Total pwd hashes: 100 > Total unique salts: 1 > Pwds tested/sec: 1.489019e+09 > Crypts tested/sec: 1.489019e+09 > Combinations tested/sec: 1.490530e+11 > > C/c: 100.10147016257012 > c/p: 1.0 > p/c: 1.0 > C/p: 100.10147016257012 These ratios make more sense now, but in absolute terms these speeds in the billions look unrealistic for the iterated hashes you previously mentioned you were testing with. So I guess something else is still wrong in your analysis script. > Is it accurate to interpret that JtR creates a rainbow table - No, absolutely not correct. Rainbow tables had their time (a few years a couple of decades ago) and their uses for unsalted hashes, and occasionally still find their uses in rare special cases, but are not a good choice for most practical purposes, and were never used in JtR. Moreover, I guess your reference to them was colloquial rather than literal - you probably meant a precomputed table in general, not a rainbow table specifically. However, the answer would be no anyway. > based on > candidate passwords generated from rule set (and/or wordlist) - that > includes crypts computed with a repeat candidate password for each salt > encountered in the password file? I don't know how exactly to interpret what you wrote, so I'll explain in my own words: As I had mentioned, JtR does reuse the hashes it computes for multiple comparisons against possible multiple loaded hashes sharing a salt. However, this does not require maintaining any optimized nor long-term table of the computed hashes, except for having the set of just-computed hashes in memory. In the simplest case, you simply have one computed hash at a time and you loop over all loaded hashes that have the same salt. So you only store one currently computed hash in memory. In the more complex case, which is what JtR typically has, multiple hashes are computed in parallel, and the current batch of computed hashes for the current salt (but different candidate passwords) is then mass-compared against the loaded hashes sharing this salt. This mass-comparison operation is optimized in some ways, including through having performance-efficient data structures (bitmaps and hash tables) built out of loaded hashes (but not out of just-computed hashes). > 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. OK so far. As a special case, JtR may omit duplicate hashes on loading, in which case the guess count and g/s reported while cracking will be limited to those hashes it had loaded. "john --show" may then show a larger number of guesses (including duplicates that might have been omitted before). As another special case, for a few especially weak hash types such as LM and bigcrypt, JtR may split input file's hashes into halves at loading, and then it counts the individual halves as hashes and for successful guesses during cracking. Again, "john --show" will correct for that in its output of actual plaintext passwords, combining the half-guessed plaintexts, but not in terms of its final line with the counts, which will continue to count the halves individually. Given the hash types you're working with, you might face the first special case (as you appear to deliberately play with reused salts), but probably not the 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. This could have been right, except that historically "crypt" refers to the Unix crypt(3) function, and thus to the process and effort of computing a password hash - not to the computed hash value. So it's OK to say "crypts per second" meaning the computation made and effort incurred per second (even though crypt(3) is not normally used in JtR, and multiple hashes are normally computed in parallel). But we don't say "if a crypt matches ..." or the like. We say "if a computed hash matches ..." > 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. That's correct. > Therefore, I should not refer to c/s as crypts tested, but crypts > generated, correct? This could have been correct, but we say "hashes computed". Alexander P.S. I've now changed the sha1crypt "--test" benchmark to assume 20000 iterations. This is in bleeding-jumbo. This is to match hashcat's default for its benchmark, which was presumably chosen to be similar to iteration counts seen on those hashes on Juniper routers and switches. There doesn't appear to be any commonly used default iteration count for sha1crypt, except that https://rchouinard.github.io/phpass/api/class-PHPassLib.Hash.SHA1Crypt.html uses a default of 40000, but I decided that benchmark-compatibility with hashcat is more important for us.
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.