[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210409095448.GA19235@openwall.com>
Date: Fri, 9 Apr 2021 11:54:49 +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 Thu, Apr 08, 2021 at 03:39:38PM -0700, David Sontheimer wrote:
> I'd like to compare apples-to-apples cracking times for heuristics
> commonly seen in user-password generation (popularized by XKCD). I'm
> grabbing the std_err output from each fork and generating summary
> stats for a single cracking run. Time and guesses/sec are easy to
> interpret. Unfortunately I'm a little confused with p/s, c/s and C/s.
> I dug up:
>
> p/s: passwords-tested/sec
> c/s: crypts-computed/sec
> C/s: crypts-tested/sec
>
> (https://www.tunnelsup.com/getting-started-cracking-password-hashes)
This is about right, but the uppercase "C" stands for "combinations".
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.
> Shouldn't JtR compute more hashes than it tests - not the other way
> around?
No, it should test at least as many combinations, and sometimes more,
than the number of hashes it computes. When all salts are different (or
the hash type is unsalted), these numbers will match. 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).
> And what's the significance of computing and/or testing hashes
> that JtR doesn't test as passwords?
This question doesn't apply.
> I'm also attempting to reproduce password hashes via Python's passlib
> library - with the same specs as JtR's test function. Ideally, I
> should see a similar relative c/s generation between algorithms. Are
> these values correct for the following parameters?
>
> Bcrypt: 32 iterations.
Yes, that's what we benchmark bcrypt with.
> Sha-256: 5000 iterations.
I assume you mean sha256crypt. Yes, that's its default and what we
benchmark it with.
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.
> Sha-1: Rounds of both 64k and 40k... So c/s results in an average of
> generating each?
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.
In general, though, when "--test" reports two iteration counts, it means
that the same number of candidate passwords was tested against each of
the two hashes in the benchmark. The reported speed is similar to what
you'd achieve in actual cracking if you loaded two hashes like this at
once. No, it isn't the average of speeds you'd achieve for the two
hashes individually, but it is roughly what you'd achieve for a hash
with the average iteration count of these two. Such mixed iteration
count benchmarks are usually not intentional (they are a result of us
having such test vectors). We should probably fix sha1crypt's benchmark
to use just one iteration count. Meanwhile, you can lock the benchmark
to one of these two iteration counts using:
./john --test --format=sha1crypt --cost=40000:40000
or:
./john --test --format=sha1crypt --cost=64000:64000
sha1crypt isn't in much use. I think you shouldn't care about it.
> Argon2: time/rounds = 1, memory_cost = 2, parallelism = 3... what's
> the final cost (value of 4 in the example below)?
>
> > Benchmarking: argon2 [Blake2 AVX]... (72xOMP) DONE
> > Speed for cost 1 (t) of 3, cost 2 (m) of 4096, cost 3 (p) of 1, cost 4 (type [0:Argon2d 1:Argon2i]) of 0 and 1
> > Raw: 3291 c/s real, 46.8 c/s virtual
"cost 4" here corresponds to Argon2 algorithm flavor. We currently
support Argon2d and Argon2i. We should also add Argon2id.
You can lock Argon2 benchmarks to either Argon2d or Argon2i with:
./john --test --format=argon2 --cost=0,0,0,0:0
or:
./john --test --format=argon2 --cost=0,0,0,1:1
The rest of Argon2 parameter values are: t=3, m=4096, p=1.
Alexander
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.
