Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 5 May 2021 13:11:18 +0200
From: Solar Designer <>
Subject: Re: Cracking stats: p/s, c/s and C/s. Hashing cost factors.


On Wed, May 05, 2021 at 12:11:14AM -0700, David Sontheimer wrote:
> Apologies for the slow response time.

No problem.

> I was able to change sha1crypt to a single 40k iteration count - much
> appreciated - this will be a bit simpler to explain to my audience.

I suggest that you upgrade to our latest code off GitHub, which will use
20k iterations for benchmarking sha1crypt by default.

> Is there documentation on the format of the --cost arguments for Argon2,
> bcrypt, sha256_crypt, and sha512_crypt? I'd like to run benchmarks with the
> costs matching the lowest that Passlib allows. For example, Passlib allows
> a minimum of 1000 rounds for sha512_crypt, while John defaults to 5000.
> When I attempt to alter the cost for these hashes it appears to either not
> effect the result, or I receive an error:
> FAILED (--cost pruned all 8 test vectors)

The "--costs" option is documented in doc/OPTIONS.  The numbering of
tunable costs is reported for each hash type when you benchmark it.

However, you cannot set them to arbitrary values without running into
that issue you noticed.  We still only use the test vectors that we
have, but possibly fewer of them as limited by "--costs" criteria.

For arbitrary values, you need test hashes that use those values, and
you wouldn't use "--test" but would run cracking sessions.

> For example, if I use 72 forks, but only load ten password hashes (all
> sharing one uniform salt) then does John generate a batch of candidates
> across forks, and mass-compare against all ten loaded hashes... then repeat
> until matching candidates have been found for all ten loaded hashes?

The number of forks and the number of hashes are unrelated to each
other, so I don't know why you mention them in the same sentence.
Anyway, in your example each forked process generates its own batches of
candidates and mass-compares them against all ten loaded hashes.  Yes,
new batches of candidates will be generated until there are either no
more candidates to generate or no more hashes left uncracked.

Also note that you posted benchmarks for OpenMP, but are talking about
forks here.  These behave differently.  My answer above is about forks
since that's how your question was worded.

> I'm now cracking randomly generated passwords of short lengths, consisting
> of only digits. I'm using iterative mode with both min-len and max-len
> constrained by the known length of the cleartext (eg: if cleartext_len = 4,
> then min-len=4 and max-len=4), with an alphabet of "Digits."

It sounds like you're using "--incremental=Digits".

> It appears that without min-len equivalent to max-len, John has internal
> logic to begin with common password lengths. But with these constraints, in
> what order does iterative mode generate candidates by default? I  imagine
> John could generate candidates by iterating through the bounded
> search-space by unicode value, regardless of number, letter or special
> character. Character frequency analysis? Something else? Not a random seed,
> no?

As doc/MODES says:

"this mode deals with trigraph frequencies,
separately for each character position and for each password length,
to crack as many passwords as possible within a limited time."

> If there is complex logic in the generation order, is this contained within
> the config file?

There is this in john.conf:

File = $JOHN/digits.chr
MinLen = 1
MaxLen = 20
CharCount = 10

Most of the complexity is inside digits.chr, and we're just now having
another discussion thread in here on what training set to use best, and
how exactly, when generating those files.

> Similarly, how does John generate candidates from a wordlist, or mask +
> wordlist?

I don't know what a helpful answer would be here.  I suggest that you
start with doc/MODES and then ask more specific questions.


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.