john-users - Forcing keys_per_crypt to 1 (was: how to print our the number of guesses john the ripper makes to crack a password)

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 17 Oct 2011 02:46:12 +0200
From: magnum <john.magnum@...hmail.com>
To: john-users@...ts.openwall.com
Subject: Forcing keys_per_crypt to 1 (was: how to print our the number of
 guesses john the ripper makes to crack a password)

On 2011-10-15 14:23, JimF wrote:
> From: "Frank Dittrich" <frank_dittrich@...mail.com>
>> Am 13.10.2011 18:14, schrieb magnum
>>> BTW, another thing I've been contemplating for lab studies is a command
>>> line option for pegging keys_per_crypt to 1 regardless of what the
>>> format says. 
>>
>> What about adjusting the dummy format (or copying dummy to dummy1 and
>> adjusting that one)?
> 
> A change such as this, would (should) have little impact on any format.  It is probably very easy to do, by simply making a change in john.c in the initoneformat so that if we are running in this mode, that this function would simply set min and max candidates to 1 for all initialized formats.  I believe this is all that is needed.  From that point on, all of the core john functions will only pass off a single candidate at a time to be tested by each format.  Slower (much slower for some formats), but for certain things, people want behavior like this.  Not every task with JtR is a balls to the wall all out speed race to find a cracked password.
> 
> However, as Magnum has mentioned, it would also need to be fully tested (the test suite rocks for this), to make sure that there are no bad side effects in the formats.  I believe that some formats have min=max or min != 1.  I do not think this will cause any problems, dropping them back down to 1 only, but it is still to be seen.

I just uploaded an experimental implementation to the wiki as patch
0028. Option is -mkpc=N and N can be anything between 1 and the format's
default max.

I've done some testing and everything seems fine.

magnum