Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 12 Apr 2021 14:41:48 -0700
From: David Sontheimer <>
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?


On Mon, Apr 12, 2021 at 11:48 AM David Sontheimer <> 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.