[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 6 Jun 2006 13:54:19 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: to MPI or not MPI john?
On Mon, Jun 05, 2006 at 11:54:06PM +0200, Otheus (aka Timothy J. Shelling) wrote:
> 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).
Well, sharing john.pot across multiple servers requires NFS (or another
network filesystem). But if you would depend on the file being shared
even with your MPI code, then indeed you can get rid of MPI.
> 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 .
I think that it is better to check the pot file's size at regular time
intervals. It is irrelevant whether the node itself "has enough log
information".
> 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" ...
I had suggested one at the end of this message:
http://article.gmane.org/gmane.comp.security.openwall.john.user/810
"Perhaps doing it at the beginning of crk_salt_loop() is safe, but I did
not verify that."
If that's what you do, it should work for all but "single crack" mode.
Of course, this "word checksumming and skipping" approach is far from
perfect. It won't scale well, except with slow salted hashes (and
multiple salts actually loaded). Its only advantages are simplicity,
generality, and preservation of John's near-optimal ordering of
candidate passwords (as long as all nodes remain online and are of the
same performance).
Thanks,
--
Alexander Peslyak <solar at openwall.com>
GPG key ID: B35D3598 fp: 6429 0D7E F130 C13E C929 6447 73C3 A290 B35D 3598
http://www.openwall.com - bringing security into open computing environments
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.
