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