Openwall Project   /home  Owl  JtR  Pro  crypt  pam_passwdqc  tcb  phpass  scanlogd  popa3d  msulogin  /  Linux  BIND  /  advisories  presentations  /  services  donations  /  wordlists  passwords  /  community  lists  wiki  CVSweb  mirrors  signatures
bringing security into open environments
 
Order Openwall Wordlists CD (20+ languages) with delivery worldwide or download
[<prev] [next>] [thread-next>] [month] [year] [list]
Date: Mon, 5 Jun 2006 23:54:06 +0200
From: "Otheus (aka Timothy J. Shelling)" <otheus@...il.com>
To: john-users@...ts.openwall.com
Subject: to MPI or not MPI john?

I think we agree that making jtr run as fast in parallel is a Good Thing.
The question is, should it be done with MPI?

Solar sent me (privately):

>  I still don't think that MPI is the right thing
> to use for this,


I'm now tending to agree. If I can get John to use the john.pot file to
share cracked keys among concurrent instances, then MPI would be a complete
waste, and cumbersome (becuase in the least it's yet another thing to have
to make portable). Here's my idea how to make john run faster in parallel.

Assume I use some filtering function (like my chksum, but more optimal, like
CRC as Solar suggested) to distribute the search of keys to the N tasks.
Every time john has enough log information flush the logs, the size of the
pot file is compared to the last known size. If it differs, the flush
completes and then a flag is set . At an appropriate point in the code, that
flag is checked, and if it is set, the pot file is re-read; cracked keys are
eliminated, and empty salt lists are pruned, causing (if necessary) the
current crack loop to be restarted with the next salt.

That's the idea. If someone can give me some guidance on "the appropriate
point" or other useful tips, I'l code up something by next Monday and
provide some benchmarks.


-- 
Otheus
otheus@...il.com
+43.650.790.2571

Hosted by DataForce ISP - Powered by Openwall GNU/*/Linux