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.