Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 16 Nov 2005 12:09:56 +0300
From: Solar Designer <>
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:
> >
> >
> > 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:

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>
GPG key ID: B35D3598  fp: 6429 0D7E F130 C13E C929  6447 73C3 A290 B35D 3598 - 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.