[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <480C9C23.60500@gmx.net>
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
