Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 15 Nov 2023 09:00:34 +0100
From: magnum <>
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.


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.