Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bf154d68511fb70120e2f5982e587d5a@smtp.hushmail.com>
Date: Mon, 23 Jul 2012 01:16:54 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Some more external mode definitions

On 2012-07-20 23:42, Frank Dittrich wrote:
> On 07/20/2012 08:39 PM, Frank Dittrich wrote:
>> BTW: I should try to write a patch which makes the max. password length
>> (for the format, or specified using --stdout=LENGTH) available in
>> external modes.
>> Then, the external mode could stop if the length exceeds the max. length.
> 
> Now I did exactly this.
> I created a new predefined external mode variable "maxlen" (filled
> either from the --stdout[=LENGTH] value (default 125) or from the
> format's PLAINTEXT_LENGTH.
> 
> I made use of it in the [List.External_base:Repeats] section,
> and removed "maxlength" here.
...
> Other external modes which generate more candidates per length shouldn't
> switch to "maxlen" instead of the current limit.

Most external modes are quite fast anyway. IMO we should use maxlen for
many of them.

> Instead, they might consider reducing the hard coded max. length in
> init(), should the format specific maximum length or the length
> specified with --stdout=LENGTH be shorter than the hard coded maximum
> length.
> Otherwise, these external modes would effectively produce duplicate
> password candidates.

For some modes, this is better for sure. Anyway, all external modes
should make use of maxlen, in one way or the other. Could you produce a
patch for that too? I'll take care of my Dumb16/32 modes and the
contest-tree-only modes now.

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.