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.