[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 15 Nov 2023 16:16:23 +0100
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: estimated completion times for ZTEX sometimes stay at "now"
On Wed, Nov 15, 2023 at 09:00:34AM +0100, magnum wrote:
> 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.
That's what I thought of, too.
> 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.
Unfortunately, it sounds like Royce would end up waiting for hours or
days until that line would appear, and this could well coincide with
completion of the attack.
> 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.
We'd need the calculation to consider progress at processing more salts
within the current batch of password candidates. Maybe instead of the
actual number of candidate passwords processed, we could use a virtual
number scaled by the ratio of salts processed so far. In other words,
in p/s and ETA instead of the actual but lagging p, we could use
p + kpc*saltn/salts. As a special case, on interrupt/restore we'd need
to infer the number of previously processed salts. Another special case
is "single crack" mode, where we should omit this logic.
> I guess we could mute the ETA from
> the status in more situations, with fairly trivial changes.
We probably should do at least that.
And of course the problem is not limited to ZTEX. It's just that with
ZTEX and bcrypt it's likely that Royce has many salts and slow hash and
large kpc.
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.
