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 11:48:43 -0700
From: David Sontheimer <>
Subject: Re: Cracking stats: p/s, c/s and C/s. Hashing cost factors.


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,

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.