Date: Mon, 14 Sep 2015 18:31:48 -0700 From: Fred Wang <waffle.contest@...il.com> To: john-dev@...ts.openwall.com Subject: Re: Judy array On Sep 14, 2015, at 6:03 PM, Solar Designer <solar@...nwall.com> wrote: > Fred, magnum - > > On Sun, Sep 13, 2015 at 08:28:08PM -0700, Fred Wang wrote: >> I use a 10-year-old Dell 2950 as my test environment, precisely because it uses slower memory, and more easily shows improvements. For my "standard" test case (MD5, 29 million hashes, a ~13 million entry dictionary, and best64 rules, yielding about 1 billion hash attempts to find about 1.7 million solutions) >> >> hashcat 3 minute 54 seconds >> mdxfind 1 minute 15 seconds (Judy only) >> mdxfind 47 seconds (Current code, Bloom filter + Judy) > > Fred - is this with the original best64 rules you e-mailed me, or with > the cut-down version with only JtR-compatible rules left in it (14 rules > removed)? (BTW, this best64 is currently misnamed since it contains > more than 64 rules either way.) The cut-down version was used, and there are exactly 64 rules in it with your subtractions :-) > > magnum - testing this stuff, I see that pot sync is a major bottleneck. > Since this is your feature, you might want to benchmark and optimize it > some more, or/and maybe we just want it disabled by default when cracking > saltless hashes. As it is, it's just not able to handle Fred's "about > 1.7 million solutions" in a minute - it takes several minutes to process > those guesses, so it becomes the primary bottleneck for the whole run. To test this, I took the 29m.txt file, and reversed each hash, so that no hashes would be found by John. No finds, no output. With best64, and --fork=32, I get a run time of 1:30. For --fork=16, I get 1:28. With mdxfind -t 32, I get 0:17. For -t 16, I get 0:21 So, yes, the output hurts - but the rest of John is still many times slower than it needs to be.
Powered by blists - more mailing lists
Powered by Openwall GNU/*/Linux - Powered by OpenVZ