[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <030270258ff84931703de705e7ccb609@smtp.hushmail.com>
Date: Wed, 15 Nov 2023 09:00:34 +0100
From: magnum <magnumripper@...hmail.com>
To: john-users@...ts.openwall.com
Subject: Re: estimated completion times for ZTEX sometimes stay
at "now"
On 2023-11-14 20:49, Royce Williams wrote:
> Sometimes - and I am not sure what the differences are yet - when I use
> ZTEX, the estimated time to completion starts off as the current time, and
> regularly updates to *continue* to be the current time, for hours or days
> of attack.
>
> Even if this is a symptom of something under the user's control - like an
> inefficient attack - I would expect that to be a UX issue worthy of fixing
> (if feasible). Is there some way to improve this?
One situation where I think this happens is when you have plenty of
salts and a slow hash. If you start an attack and press a key after some
time, but not a single complete batch of candidates has been processed
*for all salts* yet, then you'll get out-of-whack status and a tell-tale
p/s figure of 0.
If you press 'd' instead of "any key" you'll get a "Delayed status
pending..." message and then it will wait until next (or first) batch
*just* completed all salts - and at that time emit a status line. That
line will be as correct as it gets. Sometimes ETA is incorrect anyway,
such as when permutation rules take different time to process. But for
eg. mask mode, a delayed status line will often be fairly accurate even
very early.
That's for the "why". How to improve it, I'm not quite sure. Personally
I'm so used with how things work I don't really need anything better but
I understand most users would :-) I guess we could mute the ETA from
the status in more situations, with fairly trivial changes.
magnum
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.
