[<prev] [next>] [<thread-prev] [thread-next>] [day] [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.
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.
