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.