Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 11 Nov 2016 11:34:38 +0100
From: Patrick Proniewski <p+password@...atpro.net>
To: john-users@...ts.openwall.com
Subject: Re: alter default rules or filter, best way to focus on proper candidates?

On 09 nov. 2016, at 23:36, Solar Designer wrote:

> As you can see, the total running time may also drop, so filters may
> nevertheless be beneficial if you're sure none of those extra candidates
> would result in a successful guess, but you can rarely be sure.


the performance gain or loss is very hard to guess before hand, as it depends on the match between used rules and real passwords in the dump…


> Filter_LowerNum is unoptimized.  It was meant for use when generating
> .chr files only - a task that isn't nearly as performance-critical.
> 
> You should be able to achieve slightly better speeds with the Policy
> external mode instead.  To make it work similar to Filter_LowerNum,
> delete these lines from it:
> 
>        c = 'A';
>        while (c <= 'Z')
>                mask[c++] = 2;
> 
> (that is, exclude uppercase letters from those allowed by policy) and
> adjust the expected mask from 0x107 to 0x105 here:
> 
>        if (seen != 0x107 || i != 8)
> 
> Oh, and also exclude the "i != 8" check (this is a length check).


thanks. Would it be interesting to use "i != 10" inside Filter_LowerNum instead of '--max-length=10' at command line?


> Once again, for fast hashes like yours I would not recommend any
> filtering, whether optimized or not.



thanks,
patpro

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.