Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 6 Jun 2006 13:54:19 +0400
From: Solar Designer <>
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

> 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:

"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).


Alexander Peslyak <solar at>
GPG key ID: B35D3598  fp: 6429 0D7E F130 C13E C929  6447 73C3 A290 B35D 3598 - 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.