[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121213013052.GA11132@openwall.com>
Date: Thu, 13 Dec 2012 05:30:52 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Run-time change of a format's max length
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.
> > 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. %-)
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.
