[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 10 May 2021 20:44:34 +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 Sun, May 09, 2021 at 08:09:47PM -0700, David Sontheimer wrote:
> Does each fork have a fixed range of potential candidates to generate and
> compare against all hashes, regardless of salt? If a subset of hashes
> shares a salt, all hashes are compared against the same candidate?
This isn't how I'd have worded this, but if I understand what you
probably meant correctly then the answers are yes and yes.
Each forked process has its pre-determined set of candidate passwords
to generate and to hash and to compare against all loaded hashes.
(I wouldn't call it a range. It is a subset of the total, but calling
it a range could be misleading.)
For generated candidate passwords, hashes are computed for each target
salt (that is, for each salt ever seen among the loaded hashes), and are
then compared against loaded hashes that have that salt.
You might find slides 7 to 10 in this presentation helpful:
https://www.openwall.com/presentations/BSidesLjubljana2017-Yescrypt-Large-scale-Password-Hashing/
> I read that you're running experiments/simulations
> with a fixed number of candidates - is there an option or line in john.conf
> to limit candidates in mask or incremental mode?
There are these options:
--max-candidates=[-]N Gracefully exit after this many candidates tried.
(if negative, reset count on each crack)
--max-run-time=[-]N Gracefully exit after this many seconds (if negative,
reset timer on each crack)
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.
