[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5b21563de8761405b2a55d4291bd5b7e@smtp.hushmail.com>
Date: Fri, 14 Dec 2012 03:23:11 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Run-time change of a format's max length
On 13 Dec, 2012, at 2:30 , Solar Designer <solar@...nwall.com> wrote:
> On Thu, Dec 13, 2012 at 02:20:10AM +0100, magnum wrote:
>> On 13 Dec, 2012, at 1:15 , Solar Designer <solar@...nwall.com> wrote:
>>> Shouldn't this option be called --max-length instead, and we'd have
>>> --min-length too?
>>
>> That has crossed my mind too, I should change it.
>
> Yes, please. They're called that way on my to-do list. ;-)
>
>> This would let us run incremental with a length range without having to define a temporary in john.conf. Is there any other use of min lengths? Markov mode perhaps.
>
> For example, excluding too short passwords with a wordlist run, assuming
> that those are (to be) searched exhaustively with incremental mode.
All the above are done & committed now, except Wordlist and Single mode. Two new variables were added to External: req_minlen and req_maxlen and these are now used in most External modes in john.conf (still together with cipher_limit). Markov and Incremental work fine. A couple of things are now obsolete or redundant:
* The various length-variants of Incremental, eg. All7. This can now be specified at will, without hacking john.conf.
* The various length-variants of External:Double.
* The length-range given with the --markov=OPTIONS blob. They can co-exist but if both are given we should bail out with error.
This obviously needs some regression testing but everything seems to work fine and it's not that intrusive. I love this patch.
>>> Yes, maybe we need to introduce a new interface - or rather, just a new
>>> convention - that plaintext_length may be reduced by a cracking mode, in
>>> which case the format _may_ (but is not required) to make use of this
>>> info and actually stop supporting longer passwords (that it previously
>>> could support). I guess it'd check for the possibly-lowered
>>> plaintext_length at the start of crypt_all() and call a re-init function
>>> if so. With GPU formats, there's a lot of work being done per
>>> crypt_all() call, so this extra if/call will probably not cost much.
>>
>> Yes. Hopefully we can do with just a convention.
>
> Here's an issue: what if another cracking mode is run after incremental?
> Right now, incremental is the last pass in batch mode (pass 3), but this
> might change. OK, incremental may store the old plaintext_length in a
> local variable, and restore it before returning control. %-)
Yes. I am experimenting with run-time change of max length in ntlmv2-opencl but it's too rough to be committed. There are some situations or consequences I need to consider.
magnum
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.
