john-users - Re: Speed up John

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 16 Nov 2005 12:09:56 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Speed up John

On Wed, Nov 16, 2005 at 09:54:42AM +0100, Michael Behrisch wrote:
> Am Dienstag, 15. November 2005 21:49 schrieb Solar Designer:
> > 	http://www.kraeh.info/html/manual.html
> >
> > Basically, this suffers from the same problem that dJohn and most other
> > similar hacks do.  Unlike John the Ripper itself, these programs or John
> > patches would not try candidate passwords in an optimal order.  As a
> > result, John running on a single CPU for one day might crack more
> > real-world password hashes than dJohn or JohnNet running on 10 CPUs
> > would.
> 
> I don't know anything about the way those tools generate their 
> (packages of) candidate passwords,
> but if they use john --stdout to generate them, your objections
> would not apply, would they?

You're correct.  None of these John hacks I've seen use "john --stdout".

"john --stdout" would require more bandwidth and would not scale too
well, though, -- but it's fine for the slower hashes and for not too
many nodes.

BTW, this one is smarter in the way it splits the keyspace:

	http://cse.unl.edu/~rlim/jtr-mpi/

However, I do not think it is suitable for real-world use.

In my opinion, general-purpose parallel processing libraries such as MPI
are inappropriate for this task, except if the implementation is to be
used for research purposes only.

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