Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [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

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ