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.