[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
