[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150826023324.GA931@openwall.com>
Date: Wed, 26 Aug 2015 05:33:24 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: The ETA for -single is somewhat useless
On Tue, Aug 25, 2015 at 01:30:58PM -0500, JimF wrote:
> At least for slower hashes, with a large working set and or few rules.
> The ETA simply does not show up, and when it does, it is at 50% or 75%,
> etc and stays there for a LONG time. I am not sure how easy getting this
> working properly would be, but as it stands, it has no useful value.
>
> This is not a bug we can simply fix in jumbo. It is a john-proper issue.
This problem is only that bad when you have unusually few rules. With
the default ruleset, the reported percentage of work done usually grows
in 1% steps.
Also, it's not just a reporting issue: this granularity coincides with
how much work will be redone if you interrupt and restore.
In fact, this is very similar to what happens in other cracking modes
when you use GPUs or high OpenMP thread counts with very slow formats
with many different salts. With a short wordlist, you might get e.g.
50% or even DONE reported right away, but this only means that many of
the candidate passwords have been buffered and are yet to be tested
against all salts (have only been tested against some of the salts by
the time this status appears).
An enhancement for status reporting for such cases would be to consider
the percentage of salts processed for the current bunch of candidate
passwords. However, this wouldn't address the issue of work redone on
interrupt/restore. In fact, for those of us familiar with the issue and
the current way of reporting, this change would prevent us from easily
predicting how much work would be redone if we interrupt and restore -
and predicting this is sometimes useful for decision-making. Maybe the
expected percentage of work to be redone on interrupt and restore needs
to be calculated and reported separately, then.
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.
