[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 12 Apr 2021 14:41:48 -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.
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
Is it accurate to interpret that JtR creates a rainbow table - 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?
Cheers,
-David
On Mon, Apr 12, 2021 at 11:48 AM David Sontheimer <
david.sontheimer@...il.com> wrote:
> 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.
