[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20150826034355.GA2312@openwall.com>
Date: Wed, 26 Aug 2015 06:43:56 +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 11:16:58PM -0400, jfoug@....net wrote:
> ---- Solar Designer <solar@...nwall.com> wrote:
> > Also, it's not just a reporting issue: this granularity coincides with
> > how much work will be redone if you interrupt and restore.
>
> If this is a buffered granularity issue (which became VERY apparent with the number of
> candidates in formats like sha512crypt in recent CMIYC). and we pre-build this buffer,
> and track it while running, then we could write code to store off this list, and upon resume
> reload it.
For cracking modes other than single, we don't even need to store and
reload this buffer. Those same candidate passwords are already quickly
regenerated when you restore. What you'd want to save and restore,
which isn't being done now, is the current salt being tested. Yes, this
sounds like an enhancement we can actually make, along with keeping
track of salt progress for the percentage and ETA reporting.
For single crack mode, this is slightly trickier. We may be at
different rule numbers for different salts. Right now, only the oldest
still in use rule number is saved and restored. Ideally, we'd need to
save and restore those per-salt rule numbers, but this means a larger
.rec file (or a separate file), and this in turn reduces reliability
over system crashes.
Another issue is that, although the per-salt candidate passwords are
already regenerated on restore, some planned work is getting lost and
not re-introduced (not now, and not with the changes discussed above):
specifically, successful per-salt guesses only from the current run are
being retested against all other salts. (A feature which you've made
optional with a recent commit to jumbo. When it's disabled, this issue
obviously disappears along with the feature.)
> In the same manner, ETA could be deal with at time of actual work being done,
> vs jumping to 50%, and sitting there for a day, then jumping to DONE and sitting there
> for a day. Like I mentioned in the github issue posted about this issue, there is almost
> no usefulness for ETA for this situation. Yes, it does give you a bit of insite to the amount
> of queue'd work, but any form of ETA is pretty laughable. I am told the run will be over in
> a couple minutes (when it starts out), and then 20 hours later it is over.
I agree the ETA is broken. But it's a jumbo specific thing, so I am not
responsible for it and it's yours to fix. ;-)
> I did not say it was an easy problem, just that if it 'can' be improved upon, then possibly
> we should look into it.
Agreed.
I think it's preferable to approach the instances of the problems
affecting all modes other than single first. It's simpler and it will
be of greater help. Hopefully, most of this can be done in a generic
manner, in cracker.c rather than in each cracking mode individually.
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.
