[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 16 Sep 2015 22:54:50 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: fast hash processing bottlenecks
On Wed, Sep 16, 2015 at 02:41:10PM -0500, jfoug wrote:
> On 9/16/2015 2:31 PM, Solar Designer wrote:
>
> >A "rules first" mode would help greatly (apply each rule to current
> >word, then advance to next word; right now, we do it the other way
> >around, which works better for probability-optimized rulesets and slow
> >hashes).
>
> I would really like a mode like that (especially the ability to choose
> between depth or breadth first from command line)
Agreed. magnum?
> Rules are pretty slow (when dealing with fast hashes). that is why I
> was very happy when mask came out, and was damn near the speed of the
> format, while still allowing some good mangling (at least prepend/append
> which catches a damn lot of RW cracks). Is it much worse for jumbo than
> for john-proper ?
In my tests today, I measured roughly a 10% slowdown with wordlist+rules
in jumbo as compared to 1.8.0 release, when not enabling jumbo's
wordlist pre-loading or mmap. With -mem=0, jumbo becomes much faster
than core (but I suppose there's still that ~10% hit included somewhere,
so there's room for making it faster yet by removing that).
BTW, I think WORDLIST_BUFFER_DEFAULT should be bumped up (and this
reflected in doc/OPTIONS). The current default of 5000000 is very low
compared to bitmap and hash tables sizes that JtR may use by default
when run on large hash files. I suggest 1 GB for the new default.
Also, I think we should print a warning when a wordlist exceeds the
limit for pre-loading.
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.
