Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 21 Apr 2008 15:52:35 +0200
From: Markus Friedel <markus.friedel@....net>
To: john-users@...ts.openwall.com
Subject: Re: John + Boinc

Sorry for my late response, but i have to do some extra work ;-)


Solar Designer schrieb:
> RB and Simon have already provided some good responses (thanks!) but
> I'll add a few comments as well:
> 
> On Wed, Apr 02, 2008 at 09:27:44AM +0200, Markus Friedel wrote:
>> I need something like a wrapper around john. So that i can control john
>> via Boinc.
> 
> I am not aware of any existing efforts specific to JtR & BOINC, but
> there have been many other efforts to introduce distributed processing
> into JtR.  I have a collection of 7 implementations here:
> 
> 	ftp://ftp.openwall.com/pub/projects/john/contrib/parallel/
> 

Thank you, i tested some implementations, but the idea is to get it done 
with boinc :-)

> On Wed, Apr 02, 2008 at 08:46:33AM -0600, RB wrote:
>> The crux of the matter is that parallelizing a
>> workload like JtR intelligently is not a small problem, mostly due to
>> the intelligent candidate password ordering it does.
> 
> Yet some of the implementations actually got it right.
> 
>> Additionally, the heavy use of assembly makes non-local (networked)
>> parallelism much harder.
> 
> I don't see a problem here.
> 
>> Probably the most successful parallelization attempt is John
>> Anderson's maintenance of Ryan Lim's MPI patchset
> 
> I agree.  Most importantly, this one is actually maintained - it is not
> one of those academic projects that get abandoned in a month.
> 
i have tested it and it worked great!

> On Thu, Apr 03, 2008 at 06:15:15PM +0200, Markus Friedel wrote:
>> i have about 80 AMD Dual-Core Opteron 180 / 2.4 GHz with each 4 gig RAM
> 
> Your RAM won't be needed.
> 
>> also i have 400 Passwords form LDAP.
> 
> You haven't mentioned the hash type.  Is it salted or not?  How many
> different salts?

I have two kinds of hash types. MD5 and DES both are salted and all have 
different salts.
> 
>> My first thought was to deploy one passwd to each PC and let work them
>> for some hours.
> 
> That would be inefficient because there's a lot of common work in
> processing a candidate password against different hashes - especially
> against saltless ones.  For saltless hashes, you're better off keeping
> them all on just one machine rather than spreading them over all of your
> machines like that.
> 
>> The seconde thought was to deploy the same passwd to all PCs and split
>> the range of the wordlist they have to use.
> 
> This is a lot better, however wordlist-based cracking is usually fast
> enough to be performed on just one machine.
> 
> What you may do is use "incremental" mode and distribute the work across
> a few of your machines manually, with different MinLen/MaxLen settings.
> For example, for 4 CPU cores (2 of your machines), you could use lengths
> 0 through 5 on one CPU core, then 6, 7, and 8 on the remaining three,
> respectively.  Yes, 78 out of your 80 machines will just stay idle.  To
> make use of them all, you really do need one of those distributed
> processing hacks of JtR.
> 
>> So i don't know if it is the right approach to use my ressources to get
>> some of the passwords cracked.
>> The purpose of this project is to find weak passwords and shows it to me
>> which are the ones.
> 
> I suggest that you start by running a single instance of JtR on just one
> machine.  Chances are that you will get a lot of passwords cracked.
> Then you'll decide what to do next.
> 
> Good luck!
> 
> Alexander
> 

Simon was so kind to send me his version of john with the markov mode. 
and perhaps this is the way to get it work on the diverent cpus.

> P.S. Markus, you posted your first message on this topic as a "reply" to
> an unrelated message.  This results in incorrect threading in some
> web-based archives of this mailing list.  Can you and others please be
> more careful about this?  Whenever you post something on an entirely new
> topic, post the message anew, not as a "reply".  Simply changing the
> Subject may not be enough to break the thread.
> 
ups, sorry. i will watch for it the next time.

-- 
To unsubscribe, e-mail john-users-unsubscribe@...ts.openwall.com and reply
to the automated confirmation request that will be sent to you.

Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.