[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130428000623.GA14688@openwall.com>
Date: Sun, 28 Apr 2013 04:06:23 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: enhanced status reporting
Hi,
I've just pushed another one of my changes to the core tree to the
public CVS repository. Here's the most relevant commit message:
"Enhanced the status reporting to include not only combinations per
second (previously reported as c/s), but also guesses per second (g/s),
candidate passwords per second (p/s), hashes computed (also known as
crypts) per second (now reported as c/s). The old combinations per
second metric is now reported as C/s."
Also relevant:
"In single crack mode, avoid inflating the candidate password count (as
used for the p/s rate calculation) by passwords that came from
successful guesses for individual salts and thus are being tried for all
salts. These are reliably known not to be unique/new password
candidates, so their testing against all salts should only be counted in
c/s and C/s, but not in p/s, where they have already been counted once
(for the salt where the initial guess for each of these passwords
occurred)."
Here's an example status line:
150g 0:00:00:02 57.03g/s 1411p/s 3200Kc/s 4646KC/s jihal..crata
Here's another (batch mode, pass 3 of 3 - that is, incremental mode):
3268g 0:00:00:17 3/3 191.7g/s 1235Kp/s 1957Kc/s 2036KC/s 166jew..166j21
And yet another (wordlist mode, shows progress indicator):
2820g 0:00:00:17 1% 156.9g/s 10285p/s 4491Kc/s 4856KC/s rmod..released
bcrypt (shows low speeds):
14g 0:00:00:48 0% 0.2860g/s 0.2860p/s 945.0c/s 945.0C/s champs..family
bcrypt without such highly focused passwords being tested (fewer guesses):
4g 0:00:01:26 0.04599g/s 0.2989p/s 944.6c/s 944.6C/s 11111..11110
11111 (u1456-bf)
5g 0:00:01:27 0.05684g/s 0.2955p/s 944.6c/s 944.6C/s 11111..11110
p/s and the new c/s are only displayed for sessions started with this
new version, and for restored sessions from this new version. When
continuing sessions that had been started with prior versions of JtR,
p/s and c/s are hidden (but g/s and C/s are shown), because the old .rec
files lack information on candidate passwords and crypts count.
(Exception: in --stdout mode, old .rec files do have information on p/s,
which was previously reported as w/s in that mode. Now it is called p/s
too, just like during cracking.)
While at it, I extended the combinations counter to 96-bit.
Alexander
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.
