Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 17 Oct 2011 01:56:49 +0200
From: magnum <john.magnum@...hmail.com>
To: john-users@...ts.openwall.com
Subject: Re: filter performances

On 2011-10-16 23:11, Jérôme Loyet wrote:
> I have a single traditional DES password to bruteforce. I know its
> policy:  8 characters long (or more) and it uses at least one lower
> case, one upper case, one numerical and one "other" char.

What if the password chosen by the user was "foobarzzA123%"? This
complies with the policy but after truncation it's just lower case
letters. Because of this, I believe your best bet is to use incremental
mode fixed to 8 characters, but no filter. Unfortunately, you are stuck
with the higher number of possible candidates.

It's an interesting question anyway: External filters perform pretty bad
for fast hashes. Where is the bottleneck? Can we do anything about it?

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).

magnum

Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.