Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 6 Jun 2006 14:51:18 +0200
From: "Otheus (aka Timothy J. Shelling)" <>
Subject: Re: to MPI or not MPI john?

> On Tue, Jun 06, 2006 at 01:03:12PM +0200, Otheus (aka Timothy J. Shelling)
> wrote:
> > This I have trouble grasping. Is the problem that with unsalted or fast
> > hashes,
> > the word-checksumming-and-skipping approach spends a disproportionate
> amount
> > of time generating words that are never hased ?
> Exactly.  And things become worse as the number of nodes grows.

You mentioned a million hashes per second --- now I see your point about why
this approach is not so scalable. The "cracks per second" metric reported by
the --status command must then be including the words *rejected* by the
filter. Otherwise I wouldn't get almost perfect speedup using the internal
chksum filter.

> If that's the problem, then I should point out that with unsalted hashes,
> > it's clearly optimal to distribute the target patterns (the hashed
> > passwords) amongst the nodes.
> I re-read the above several times, but I still don't understand you.  If
> I parse the above literally, you're suggesting that with multiple
> unsalted hashes it would be optimal to have different nodes compare
> against different hashes

That is what I'm saying, assuming word generation is (even slightly) slower
than hash generation.

- but that is clearly not true.

Let's say you have a target password database of 10 hashes, and you have 2
nodes.  Each node uses the same word-generation algorithm. Give each node
half the hashes to crack. They should (on average) both complete (at about)
half the time it would have taken 1 node with those same 10 hashes.

If we have 10 nodes, and we split the target database of hashes, then it
should take (roughly) about 1/10th the time it would have taken 1 node.

How could it get any faster than that?

Is there an error in my logic, or are we completely misunderstanding each


Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ