Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 16 Sep 2015 22:54:50 +0300
From: Solar Designer <>
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.


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.