[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20050824194320.GA24037@openwall.com>
Date: Wed, 24 Aug 2005 23:43:20 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: trivial parallel processing (4 CPUs)
Stephen,
On Wed, Aug 24, 2005 at 01:20:48PM -0600, Stephen Cartwright wrote:
> I did not use the -show option.
Yes, you should be using -show rather than looking at john.pot file
contents.
> One more thing the computer I am running Jack on has 4 CPUs. To take
> advantage of this my understanding is that I should use the
> -session:FILE option and start four different processes in the
> background with different session files and -wordfile:FILE word
> lists?
Yes. However, wordlist-based cracking is generally quite fast, so you'd
probably want to play with "incremental" mode settings instead. Once
you're done with "single crack" mode and the wordlists (don't forget to
enable -rules), you could set your four instances to try lengths 0-5, 6,
7, and 8, respectively. You would define john.conf sections like this:
[Incremental:All05]
File = $JOHN/all.chr
MinLen = 0
MaxLen = 5
CharCount = 95
...
[Incremental:All8]
File = $JOHN/all.chr
MinLen = 8
MaxLen = 8
CharCount = 95
This example is for the 1.6.x development versions - which you should be
using if you care about performance.
Since the multiple instances of John would not exchange information
about already cracked passwords on the fly, you may want to interrupt
and continue the sessions after they've cracked most weak passwords
(e.g., after a few hours). Then the recovered sessions won't load
password hashes already cracked by other instances. In fact, you may do
this more than once for even better efficiency.
You would also want to set this:
[Options]
# Use idle cycles only
Idle = Y
> Do you reccomend I try DJohn instead?
No. Unfortunately, all John the Ripper hacks for parallel processing
that I am aware of result in a far less optimal order in which candidate
passwords are tried. They also tend to be unreliable.
--
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
Was I helpful? Please give your feedback here: http://rate.affero.net/solar
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.
