john-users - RE: Speed up John

Openwall Project		/home Owl JtR Pro crypt pam_passwdqc tcb phpass scanlogd popa3d msulogin / Linux BIND / advisories presentations / services donations / wordlists passwords / news community lists wiki CVSweb mirrors signatures
bringing security into open environments

Password Recovery Resources on the Net

[<prev] [next>] [<thread-prev] [thread-next>] [month] [year] [list]

Date: Thu, 17 Nov 2005 09:57:24 +1100
From: "David Luyer" <david@...er.net>
To: <john-users@...ts.openwall.com>
Subject: RE: Speed up John

Considering long runs of john (where you're running for weeks to years
over the one set of passwords), john can be run with a large wordlist in a 
reasonable amount of time (weeks at most).  No need to parallelize.  The
same with running incremental:digits or using an external to do other
sets like 9 or 10 digits.

The one thing which is slow is incremental:all.

The way incremental:all works is in passes, as you can see in the .rec 
files.  In about a month running on about 100 crypts you'd probably do
around the first 2000 passes on a fast system.

A way to distribute the load sensibly would seem to be to have a server
keep track of the passes as they are done and communicate the hashes
as they are cracked;

	server data set:
		[crypt string, plaintext string, source client id, crypt id]
		[client id, last sent crypt id]
		[sequence number, client id, start time, end time]

	client starts, requests sequence number, works on that pass of
      incremental:all; server stores sequence number, client id, start
      time

	client cracks crack password, sends it to server, server sends it
	to all online clients to add to their john.pot and updates the
      data set to know it has been sent (any offline clients get it as
      they connect)

      client ends pass and sends notice to server, server storess end
      time and allocates first non-started pass to client

If a client fails the server should be able to have an entry deleted
so that a new client will be allocated the same sequence number.

Comments?  Would this be seen as a reasonable distribution of workload
and not a particularly bad cracking sequence?

David.