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.