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.