Date: Mon, 17 Oct 2011 05:17:04 +0400 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: filter performances On Mon, Oct 17, 2011 at 01:56:49AM +0200, magnum wrote: > It's an interesting question anyway: External filters perform pretty bad > for fast hashes. Where is the bottleneck? Can we do anything about it? In this case, it's not exactly a bottleneck - the filter simply filters out something like 99% of incremental mode's candidate passwords early on. To solve this, we'd need to have policy-matching code built into incremental mode: applied to groups of passwords that would be generated rather than to individual candidate passwords that have already been generated. To measure the performance cost of the external filter from policy4.conf from my previous message, I changed "word = 0;" to "i = 0;" (also a variable assignment, but effectively a no-op one). This edited filter should have the same performance cost, but it should not filter anything out. Running with this filter on one DES-based crypt(3) hash with incremental mode and the length locked to 8, I am getting 65% of the original c/s rate. So the filter's overhead is by far not as bad as what one could think from Jerome's postings. > On a side note, you might want to check out the nsk-3 patch (a.k.a > "Faster bitslice DES key setup for JtR 1.7.8" on the wiki) unless you > already did that. Not a huge boost, but still a boost (13-14% on my gear). Yeah, and some more might be possible by using x86-64.[Sh] from CVS (post-1.7.8), and another 7% is possible by hard-coding the salt (not something I would expect an end user to be able to do, though). 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.