You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Alternatively, as magnum suggested, we should at least mute ETA until the first block of candidates has been processed or if it matches the current time.
The text was updated successfully, but these errors were encountered:
As I suggested in https://www.openwall.com/lists/john-users/2023/11/15/2
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 usep + 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.Alternatively, as magnum suggested, we should at least mute ETA until the first block of candidates has been processed or if it matches the current time.
The text was updated successfully, but these errors were encountered: