[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060529131914.GA27125@openwall.com>
Date: Mon, 29 May 2006 17:19:14 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Parallalizing John the Ripper
On Sun, May 28, 2006 at 11:29:18AM +0200, Otheus (aka Timothy J. Shelling) wrote:
> >P.S. I just found two other John/MPI hacks, besides Ryan Lim's, on my
> >hard drive - for a total of three. One of those is from 2001, the other
> >is from 2004 and in fact includes a reference to Ryan Lim's work - but
> >it's different. Yours is going to be at least the fourth...
>
> I hate to be a pain, but I did not see either of these other patches in the
> contrib section of the FTP server. It would probably be useful to me to have
> a look at the other one from 2004.
They were not of adequate quality/usability to be placed in contrib, so
I did not care to ask whether I can redistribute them. I'll see if I
can share them with you now. I don't think this 2004 hack is any good.
According to the data in their report, it did not perform too well -
with a single node doing 300k c/s (no MPI), 13 nodes were doing only
1.5M c/s, not the expected 4M c/s.
> I believe, however, it addresses Solar's "practicality" issues:
I haven't seen your code, but I doubt that it addresses all of the
issues that I was referring to.
> o Recovery: Each task runs with its own session; the whole thing can
> be re-started in recovery mode
OK, that can work - but does it mean that there's a .rec file for each
task?
> o Practical: It runs in any of the modes, not just incremental.
Actually, I see no problem with an implementation being specific to
"incremental" mode only - that could still be practical.
> It simply relies on an filter to split the keyspace.
So you're having each task skip whatever candidate passwords are
supposed to be tried by other tasks. Now, what happens if the nodes are
not of equal performance? You deviate from John's semi-optimal order in
which candidate passwords are normally tried, likely trying them in
not-so-optimal order.
What happens if a node fails?
What if you want to add/remove nodes?
> o Scalability: using the external mode to split the keyspace has a
> minor performance impact, but it seems to be very, very minor. I will do
> some performance analysis on it.
The impact is minor with slow hashes and multiple salts. The impact is
major with fast saltless hashes.
> Using this and a decent parallel machine, it should be possible to crack a
> wordlist within minutes.
Actually, this is possible with a single CPU, too - for some hash types
and some wordlists. ;-) For LM hashes, even my large wordlist (4 million
entries) with the default wordlist ruleset (producing about 200 million
candidate passwords) may be processed against any sane number of hashes
in a minute.
Of course, for slow hash types it does make sense to parallelize
wordlist-based cracking as well.
--
Alexander Peslyak <solar at openwall.com>
GPG key ID: B35D3598 fp: 6429 0D7E F130 C13E C929 6447 73C3 A290 B35D 3598
http://www.openwall.com - bringing security into open computing environments
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.
