[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20050824231328.GA2897@openwall.com>
Date: Thu, 25 Aug 2005 03:13:28 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: trivial parallel processing (4 CPUs)
On Wed, Aug 24, 2005 at 03:10:05PM -0700, Alen Williams wrote:
> On Wed, 2005-24-08 at 23:43 +0400, Solar Designer wrote:
> > Unfortunately, all John the Ripper hacks for parallel processing
> > that I am aware of result in a far less optimal order in which
> > candidate passwords are tried. They also tend to be unreliable.
>
> Hmmm, as I'm in the middle of writing one of those hacks, how should
> that be tackled?
I am sorry, but I've given up wasting time on responding to this kind of
questions via private e-mail. Now that we're on an archived mailing
list, things are a bit different. I might find the time (several hours)
to describe my thoughts on this and to answer any follow-up questions in
here eventually... although I do not expect anything to come out of
this. I feel that it would be more productive for me to implement the
thing myself (I did have a prototype working back in 1997).
> Right now the candidates in my hack are presented in the same order as
> dJohn.
Well, this only works fine in two cases:
1. When you're programming this for fun rather than for actual use, or
2. When you intend to search a pre-defined portion of the keyspace
_exhaustively_ and somehow don't care to get most of your passwords
cracked early on during the search.
In most practical cases, I would expect John running on one CPU to be
far more effective at getting weak passwords cracked within a certain
(limited) amount of time than dJohn running on 10 CPUs.
> How should I improve that?
Well, here's a really short answer: there exist fairly straightforward
enhancements of John the Ripper's "incremental" mode algorithm that
allow for parallelization, with no or little effect on the efficiency of
the order of candidates.
It is also entirely possible to support nodes of differing and changing
performance, add/remove nodes on the fly, and handle node and network
failures gracefully.
--
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
Was I helpful? Please give your feedback here: http://rate.affero.net/solar
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.
