Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 13 Dec 2012 05:30:52 +0400
From: Solar Designer <>
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 <> 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. %-)


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.